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 release" 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 unnoticed. 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 etc. 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 branch. 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. Robert Ramey Darren Garvey wrote:
On 25/08/07, Beman Dawes <bdawes@acm.org> wrote:
*snip*
/svn/boost/branches/libs/ system/ boost/ system/... libs/ system/ build/... doc/... src/... test/...
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.
Opinions?
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).
Regards, Darren _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost