Boost logo

Boost :

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

on Fri Nov 02 2007, Beman Dawes <> wrote:

> David Abrahams wrote:
>> on Thu Nov 01 2007, Beman Dawes <> wrote:
>>> David Abrahams wrote:
>>>> I hope everyone is using
>>>> 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 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 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at