On Wed, Apr 20, 2011 at 10:05:08AM -0400, Daniel Walter wrote:
> > 4.1.x-release +--------LR----------------------
> > / | +--- 4.3.x-release
> > / | /
> > / | /
> > trunk ------+---+--------|---o----------------+----
> > \ | ^
> > \ | /
> > \ v /
> > 4.2.x-release +----o------------------------
> > LR
> >
>
>
> This is a good diagram of what we are doing. The word
> cherry-picking is misleading though because we use this approach to
> periodically merge forward everything. The only cherry-picking
> would be something that we specifically didn't want merged forward
> and this is extremely rare. This is part of the reason why we make
> the bug fixes on the branches for the earlier releases. If you make
> the modifications to the trunk, you need to choose what to merge
> backwards, but if you make the modifications to an earlier release,
> you can generally merge everything forward.
Right. Note that you might easily get spurious conflicts with this strategy
if you're not careful about where changes enter the diagram and where
they get merged. Avoid cycles.
If a release branch has also received merges from trunk, the reintegrate
merge is necessary to avoid having changes replayed twice.
Say you do a sync merge like this:
cd trunk
svn merge ^/branches/4.1.x
Then the left side of the merge diff is branches/4.1.x_at_N and the right
side is branches/4.1.x_at_HEAD.
If you have already merged anything from trunk to the branch those
merged changes will now be seen as part of that diff, i.e. appear as if
they had originated on the branch. They will therefore be replayed on
the trunk working copy possibly causing spurious conflicts. E.g. a delete
will again be a delete causing a tree conflict since one side might have
renamed the deleted item and SVN isn't smart enough yet to know if that
has indeed happened so it flags a conflict to err on the safe side.
In that case, a reintegrate merge will produce something quite different.
Of course, you can continue using 2-URL merges with distinct tags as
left and right side of the merge. But you won't benefit from merge-tracking
this way. And you might also get unncessary conflicts. 2-URL merges are easy
to get wrong so it's recommended to avoid them if possible.
Received on 2011-04-20 16:35:23 CEST