On Sun, Jul 13, 2014 at 02:34:05PM +0200, Diederik van Lierop wrote:

Haven't looked at the experimental branch recently, but I guess this is the bug has been fixed in rev. 13450 of trunk. This patch has not been ported yet to experimental.

How do we go about this? Port all fixes at once from trunk to experimental, once 0.91 has been released?

Other way round: Any work on experimental that folks want to keep will need ported to trunk.

So, we're in no danger of forgetting bug fixes, but there is potential for regression if features get ported over that might overwrite them. So, there's a benefit to committing fixes to both branches.

Bryce

Or should we try to keep them in sync as good as possible at any time, and commit each fix twice? I don't really care either way, but I do believe that we should be clear and explicit about this. If we do cherry picking now and port only some bugs, then for sure some other bugs will be forgotten.

Diederik

On Sun, Jul 13, 2014 at 1:49 PM, Johan Engelen <jbc.engelen@...2592...> wrote:

...

On 13-7-2014 13:45, Johan Engelen wrote:

...

Hi Diederik, all, There is a discrepancy between experimental and trunk with regards to snapping when alt-dragging. When the grid is enabled, alt-dragging should move the selection in grid-spacing steps. But when the movement is less than one grid-spacing, there is no snapping.

In experimental, it does not work as expected. In trunk, it works fine.

-Johan

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Sun, Jul 13, 2014, at 05:34 AM, Diederik van Lierop wrote:

Haven't looked at the experimental branch recently, but I guess this is the bug has been fixed in rev. 13450 of trunk. This patch has not been ported yet to experimental.

How do we go about this? Port all fixes at once from trunk to experimental, once 0.91 has been released? Or should we try to keep them in sync as good as possible at any time, and commit each fix twice? I don't really care either way, but I do believe that we should be clear and explicit about this. If we do cherry picking now and port only some bugs, then for sure some other bugs will be forgotten.

In general it's best to keep branches in sync as close as possible to trunk when work occurs there. The longer a bugfix on trunk goes unported, the more chance there is of things breaking, including the fix. A common approach for a commercial development environment is to have either the engineer responsible for the bug fix port it forward to active branches right after having fixed it on trunk, or have a team that owns a branch designated to pull fixes from trunk to their branch right after they happen on trunk.

Of course we do need to be careful to do a proper cherry-pick of only the fix down to the branch. If done incorrectly one can accidentally mark that all of the trunk has been merged to the branch (by ignoring all the rest of the changes) and when someone later on goes for an overall merge it will show up with no diff.

With some version control systems it is imperative to do a merge of just the fix, instead of re-creating the fix by editing things brand new on the branch. I've not tested the subtleties here with Bazaar, but it can lead to some headaches with extra collisions being flagged when we do a larger merge later.

So I'd say we want to avoid doing the "commit each fix twice" thing and instead "commit to trunk then merge the fix to the branch" or "commit each fix and then merge it". A very subtle difference, but it can avoid a lot of long-term problems.

Additionally, with a branch like our experimental it is a good thing to try to refresh from trunk perhaps once every week or two. That can avoid an exponential explosion on the merge complexity we might otherwise see from waiting for a very long period.

-- Jon A. Cruz jon@...18...