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.