Re: [boost] [1.35.0] Merge tag question?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-11-14 09:05:28

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