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
>> 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
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
>>> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk