Jens Seidel wrote:
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.
We already do that. The branch is named branches/release. The question is how to keep track on an ongoing basis what has been merged into that branch and what hasn't. The point being to avoid "merge hell" which occurs when duplicate changes get merged or bi-directional merges fail to apply the appropriate changes in one direction or the other. It may be that the whole issue is moot with SVN if we follow some simple rules. See below.
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 :-).
For some development patterns, that works fine. But it falls apart in other scenarios. See http://tinyurl.com/24a3mg for a Subversion 1.5 Webcast presentation that looks at the need for merge tracking with various development strategies. Skip the marketing fluff at the beginning.
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.
Yes, but there have to be the sort of rules you mention for a strategy to work that doesn't do explicit merge tracking. The rules I'm know of are: * Do tree/tree (rather than revision/HEAD) merges into release/branches. This avoids the duplicate merge problem. * Don't make changes directly to branches/release. Always first make the changes to trunk, and then merge them into branches/release. This avoids the bi-directional merge problem. * Don't make changes to trunk that shouldn't appear in branches/release or break other libraries, until after all trunk changes for the current release have been merged into branches/release. Make such changes in a branch instead. Those rules leave out the case where a change (probably a bug fix) has to go into branches/release, but trunk has meantime been modified with changes that must not go into branches/release. The procedure for that has to be worked out. It is probably a manual trunk revision/revision merge into branches/release, but I haven't thought that through yet. Thanks, --Beman