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
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 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.
Received on 2011-04-20 12:39:00 CEST