[1.35.0] Merge tag question?
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? 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? 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 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. Thanks, --Beman
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
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
Beman Dawes wrote:
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.
Use svnmerge.py for now. See: http://www.orcaware.com/svn/wiki/Svnmerge.py ... where it summarizes: "svnmerge.py is a tool for automatic branch management. It allows branch maintainers to merge changes from and to their branch very easily, and automatically records which changes were already merged. This allows displaying an always updated list of changes yet to be merged, and totally prevents merge mistakes (such as merging the same change twice). You can think of svnmerge as the equivalent of yellow sticky notes on a Subversion branch that record which revisions have been merged in already from one or more other branches, plus some useful functionality for viewing, managing and updating that information. "
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?
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?
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?
Yes, I think this is the best solution until 1.5 comes along. -- Daniel Wallin Boost Consulting www.boost-consulting.com
participants (4)
-
Beman Dawes -
Daniel Wallin -
eg -
Jens Seidel