Re: [boost] svnmerge.py

From: David Abrahams (dave_at_[hidden])
Date: 2007-11-02 12:28:49

on Fri Nov 02 2007, Beman Dawes <bdawes-AT-acm.org> wrote:

> David Abrahams wrote:
>> on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
>> 
>>> David Abrahams wrote:
>>>> I hope everyone is using http://www.orcaware.com/svn/wiki/Svnmerge.py
>>>> when merging changes between branches and trunk.  That's very
>>>> important if we're going to avoid merge hell.
>>> The plan isn't to do what the TortoiseSVN docs call a "Range of 
>>> Revisions" merge, but rather what those docs call "Merging Two Different 
>>> Trees". 
>> 
>> Do I have to learn about TortoiseSVN in order to understand what
>> you're saying?  I don't really use Windows for development anymore.
>
> I spent about 20 minutes searching online for documentation or examples 
> of using the merge command to do what is really a copy. 

Really a copy?  There's been evolution on both the 1.34 release branch
and on the trunk since they forked.  How would doing a plain copy
fix anything?

Oh, I see; you're talking about preparing the release branch.

> I also checked the "Version control with Subversion" book, both
> paper and online versions. The TortoiseSVN docs are the only place I
> can find that mentions this use case.

If you want to copy files from one place to another, it's "svn cp".

>>> Since in effect that just copies the file from the trunk to the 
>>> release branch, there isn't any chance of merge hell, if I understand 
>>> what you mean. 

What happens when more work is done on the trunk and you find you
need to pull just some of it into the release branch?

>>> This approach also minimizes the chance that the code will break,
>>> since the code is unchanged from the code being tested on the
>>> trunk.
>>>
>>> Is there any reason to use svnmerge.py for a tree/tree merge?
>> 
>> Probably, especially if you're ever merging back and forth between two
>> trees.
>
> But we aren't really merging. We are copying, using the merge command to 
> do the copy because the copy command doesn't have an overwrite option.

The way to do that is to have a working copy that contains the branch
and the trunk, "svn rm" the branch files, "svn cp" the trunk files
over to the branch, then "svn commit"

> Hopefully the whole synmerge.py issue will go away once we change over 
> to 1.5.

Oh, it sure will.  Unfortunately I'm finding svn to be a bit painful
so far, and wondering what to do about it.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com