From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-25 13:03:19
I would add that I was quite confused about this - and still don't feel
comfortable with it. For what its worth here's what I did.
I took SVN documentation at their word that copies
are "cheap" and have no reason to doubt this.
I created a branch of the last rlease and called it "serialization next
so far so good.
Then I made changes whereever I wanted. It turns out that
the changes were in more than one directory so creating branches
on various SVN directories would be a pain in the neck.
so far so good
Checked in my changes to the branch - smooth as silk.
After a while using my changes on my own machine, merge
to "trunk" to rain the benefits of my efforts upon your world.
(This crashed the whole test system - which embarrassed
me no end - not an easy thing to do - but I digress).
The merging into the trunk was very confusing to me and
I had to spend a lot of time getting things on my machine
balled up and then unballed up. Here are a couple of things.
First of all, i had hoped I could just "merge" the changes
on my branch directly into the trunk. There may be a way
to do this with the command line interface but the windows
interface doesn't let you do it.
Probably a good thing too. Now I realise that directly merging
into the trunk could create conflicts which would otherwise go
So it turns out the way to do this is
a) switch one's directory/files you want to merge to the trunk branch.
This step is not so obvious as it seems. When I did the switch, I
switched the directory with the changes to trunk
thinking that I would end up with exactly what I have but with
the directory in question switched to the trunk. What I got was
a whole directory tree from boost root under the directory I
wanted to switch. It turns out that when you do the switch
you have to switch to the corresponding tree/file in the trunk.
Unballing this up took a while with alot of SVN errormessages
b) merge the changes from the branch (in this case
"serialization next release" in to the directory/files which
have been switched to the trunk.
c) after testing, check the changes into the trunk.
d) switch the directories/files back to your development
e) If you made any changes while in the trunk, you should
merge those back into your development branch.
There is probably an easier way to do this - maybe just having two trees
on my system like i did with CVS. I'm still feeling my way
around this thing.
Darren Garvey wrote:
> On 25/08/07, Beman Dawes <bdawes_at_[hidden]> wrote:
>> In other words, organized the sub-tree under
>> /svn/boost/branches/libs/system exactly the same way the trunk is
>> organized. That might be easier for others to understand. I also
>> wonder if it has any advantages as far as various SVN operations go.
> Since SVN copy operations are so cheap, wouldn't it be simpler to
> have each branch as a complete copy of some stable tree, with some
> isolated work stuck in? That way, a naive user (such as myself) can
> just check out a branch -
> eg. the system branch - and have a complete boost tree that they can
> test, use or develop with.
> As it stands, the 'branch' appears to be a subset of boost, whereas I
> would have expected a complete 'fork' (albeit a temporary one).
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk