From: Jens Seidel (jensseidel_at_[hidden])
Date: 2007-11-13 10:30:04
On Tue, Nov 13, 2007 at 10:03:18AM -0500, Beman Dawes wrote:
> Under CVS, we tagged files in the trunk "merged_to_RC_1_34_0" at the
> time of branching for release, and then updated the location of that tag
> if a later version of the file got merged into the release branch.
> This allows library maintainers to know what has been merged and what
> What should the procedure be for Subversion?
Tagging should not be used if the code still changes, use a branch
instead! (To be honest, a tag and a branch are exactly the same in
Subversion, just a copy of a source directory. But a user expects
to find a tagged source tree in tags/ and a branch in branches/.)
> Does Subversion have an equivalent to updating the location of a tag for
> a subset of files? Or is tagging completely the wrong approach for
Use a branch. Lets assume you want to work on RC_1_35_0 while trunk
will soon contain further changes not intended for 1.35. Do
$ svn copy -m"Created branch for 1.35 development" url_to_trunk url_to_branches/RC_1_35_0
Now you can check out RC_1_35_0 and work in it as usual.
Once the work on this branch closed it may be possible to tag this
version as well:
$ svn copy -m"Tagging version 1.35" url_to_branches/RC_1_35_0 url_to_tags/RC_1_35_0
> Should we be using svnmerge.py instead and letting its merge tracking
> handle the need to keep track of what has been merged and what hasn't?
I merged always manually and I'm happy with it (but noticed today in
one of my repositories that I missed some patches :-).
> I suspect we need to get this right the first time, so I'd particularly
> like to hear from people who have dealt with this in practice, and can
> report what worked well for them.
It is not very difficult, just decide a path name for a tagged or branched
version. Many projects do not allow working in a stable branch at all
and require that only changes from trunk are merged in the stable
branch, so trunk/ always contains all fixes.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk