> > 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.a
> dvanced.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.
If you are merging everything in there is no need to worry. That is the point of merge tracking. It will determine what has yet to be merged and select the correct revisions.
Here is how we have our repo set up... rather than using trunk. We find it makes things easier.
We basically "branch" when we start on a new release version. So we have something like this:
1.0.0------------
\
\
1.0.1 +-------------
\
\
1.0.2 +--------------
We release from the version path (branch). Any hotfixes for that version are done on that branch. Then they are merged forward "up" version. So we merge a change made on the 1.0.0 to 1.0.1 then to 1.0.2 and forward. We "try" to only have our current release (1.0.1) and one back (1.0.0) in maintenance and then the in dev version (1.0.2). Of course, you always have that one client that doesn't want to upgrade and sales/support insists we do a fix... but we still just merge it up versions until it is merged into the unreleased dev version.
BOb
Received on 2011-04-20 16:16:18 CEST