I always use branches for merging. Tags are just a "label" to get my
branch and trunk
deltas.
________________________________
From: Fedor, Halina (Mission Systems)
[mailto:Halina.Fedor@ngc.com]
Sent: Tuesday, May 08, 2007 10:30 AM
To: users@subversion.tigris.org
Subject: Which is better? Merge from Tag or Merge from Branch if
we follow a stable-trunk policy?
I have a question about best practices for merging/merge
tracking in Subversion ... I am relatively new to this but like what I
see so far w/the tool (except for no true-rename support and having to
manually track merges - pray for in v1.5!). We are following a stable
trunk policy whereby only the released version appears in trunk and all
of the development takes place on branches. Essentially the final tag
for a branch that has been built, tested and accepted will become the
production baseline that would be merged back into the trunk once the
release goes out, however, since tags are essentially snapshots of the
branch at a certain point in time (and actually carry the "history" of
the branch as well), is it a better practice (from a manual merge
tracking standpoint and generally speaking) to merge from the tag or
from the branch to the trunk once we go to production? Also, if we are
performing builds that are created from the tag (that was created off
the branch) and that tag becomes the production code, are there risks
involved with merging the final branch revision that the final tag was
created from back to trunk instead of from the tag itself? Certainly
before doing a merge back to trunk I would ensure the tag had not been
modified since it was created - likewise with the branch, if that is the
best place to do the merge from (I'd just select the range for the tag
that had been created). After the changes are applied back to trunk I
would merge those changes applied to trunk (from the tag or branch) back
to other concurrent branches. In both cases I would document thoroughly
the revisions merged back to trunk (and back to branch from the trunk).
As far as how to tackle renames we are doing a lot of
refactoring at this time so I am very interested in locating a feasible
and easy-to-understand solution so we do not run into a situation where
branch changes get wiped out by merges back from the trunk (for files
that have been renamed but exist across different branches). I have
seen some discussion on the message board about coming up with python
scripts to try to identify files that get renamed but I am not sure at
this time what other workarounds most users have implemented.
Thanks v. much for any advice you can offer.
H Fedor
Received on Tue May 8 16:52:07 2007