--------------------------------------------------
From: "Stefan Sperling" <stsp_at_elego.de>
Sent: Wednesday, April 20, 2011 6:38 AM
To: "Daniel Walter" <d2walter_at_hotmail.com>
Cc: "Bob Archer" <Bob.Archer_at_amsi.com>; <users_at_subversion.apache.org>
Subject: Re: duplicate merge conflict
> On Tue, Apr 19, 2011 at 09:34:17PM -0400, Daniel Walter wrote:
>> I understand what is going on now, but this seems to indicate that I
>> will need to look up revision numbers from tags every time I do a
>> merge in SVN. Is there any automated way of doing this? It seems
>> like a huge step backwards to go from using symbols that mean
>> something to me to using numbers that only mean something to my
>> version control software.
>
> Yes, any cherry-picking approach will require you to know which revision
> numbers are relevant to a given bug fix.
>
> The Subversion projects keeps a file on each branch for that purpose:
> https://svn.apache.org/repos/asf/subversion/branches/1.6.x/STATUS
>
> Where and how the mapping from bug fix to revision number is done doesn't
> really matter but with cherry-picking you'll need some way of identifying
> which revisions belong to which bug fix. A bug tracking interface like
> Trac
> or Redmine that integrates with Subversion can help here. You'll still
> have to enter the data e.g. adding an entry in bug tracker item #5 to say
> that revision 42 is related to bug #5. But once the data has been entered
> it is nicely linked up and can be browsed easily.
>
>> Perhaps I should be using some other form of automated merging in
>> SVN, but none of the automated merge schemes listed is remotely like
>> my merge workflow. I have three versions.
>>
>> 4.1 on a branch
>> 4.2 on a branch
>> 4.3 on a trunk
>>
>> I need to merge any bug fixes or changes that I make to the older
>> versions forward into the newer versions and then the trunk.
>> Currently I make a new tag on each branch whenever I merge changes
>> forward.
>
> It sounds like you have something like this:
>
> 4.1.x-release +--------------------------------
> / +--- 4.3.x-release
> / /
> / /
> trunk ------+---+-----------------------------+----
> \
> \
> \
> 4.2.x-release +-----------------------------
>
>
> You make fixes on the oldest release first, then to 4.2.x, then to trunk.
> You can do this by cherry-picking the appropriate revisions from one
> branch
> to another:
>
> 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.
> Many projects using Subversion make trunk the initial target of bug fixes
> and then merge those over to release branches using cherry-picking:
>
> 4.1.x-release +-----------------------o--------
> / ^ +--- 4.3.x-release
> / | /
> / | /
> trunk ------+---+----------------------LR-----+----
> \ |
> \ |
> \ v
> 4.2.x-release +-------------------o---------
>
>
>
> If you don't want to think about revision numbers the following pattern
> might help (or at least be inspiring) if you can live with (or work
> around)
> limitations explained below.
>
> unstable changes maintenance mode
> 4.2.x-release +-----------------R---------------------R.......
> / . \ . \
> / ................ \ ............... \
> / . v . v
> trunk ------+-L-----------------------o-L--+----------------o....
> rW rX \
> \
> 4.3.x-release +---------------...
> unstable changes
>
> Basically, trunk never receives direct commits but only reintegrate
> merges from the release branches. Note that in this pattern release
> branches
> represent *future* releases you haven't already released for production.
> Though maybe you did release them for testing purposes.
> Trunk is always in a releasable state. It is initially your 4.1.x-release
> and becomes the 4.2.x-release once the 4.2.x-release branch has been
> reintegrated for the first time.
> The 4.2.x-release branch now goes into maintenance mode and trunk receives
> bug fixes from it via additional reintegrate merges.
> (You need to use the trick described at
> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice
> to keep the release branch alive after reintegration.)
>
> This pattern avoids juggling with revision numbers but has some drawbacks.
> You must consider trunk to be the stable and releasable state. And you
> must
> stop maintaining older releases as soon as a new release hits trunk.
> By the time you merge 4.2.x into trunk the 4.1.x release line has reached
> end of life and will never receive additional updates.
This is an interesting pattern, but does not seem like it would apply very
well to our development because we merge forward changes on a regular basis.
>
> This pattern works only with one future release line. You can prepare the
> 4.3.x release on a release branch off trunk while 4.2.x is in maintenance
> mode.
> The 4.3.x release branch then regularly syncs to trunk to receive bug
> fixes
> originally made in 4.1.x which have been reintegrated into trunk.
>
> But in some scenarios this works quite well in spite of these drawbacks.
> E.g. this pattern is being used in practice at a web shop where trunk
> is deployed to production servers and release branches are deployed to
> testing servers. There is no need to maintain old versions of the website
> as soon as the latest release has gone live.
>
Thank you for the suggestions. After learning how this worked, I thought
there might be something that I am missing, but that does not seem to be the
case. I think at this point, my best solution is still to use tags and just
find the revisions for the tags before doing merges with svn info if I think
that a particular merge will generate a lot of conflicts.
Daniel
Received on 2011-04-20 16:05:42 CEST