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 hasn't.
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 Subversion?
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. Jens