David Abrahams wrote:
on Wed May 30 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
Rene Rivera wrote:
Ping... Any comments on this? It would be nice if people voice some comments on this subject now. Instead of later when we would have to move a bunch of directories around. Yes, this looks reasonable to me.
[boost-svn] boost stable (full boost tree here) devel (full boost tree here) branches my_branch (full boost tree here) cmake_a (full boost tree here) cmake_b (full boost tree here) tags boost_1_33_1 (full boost tree here) boost_1_34_0 (full boost tree here) sandbox devel xml (partial boost tree here) explore (partial boost tree here) branches xml_b0 (partial boost tree here) explore_b0 (partial boost tree here) tags xml_for_review (partial boost tree here) explore_for_review (partial boost tree here) I'm still not convinced that the branching in the sandbox should happen outside the projects (as opposed to let each sandbox project organize its own substructure), but I don't have a strong opinion there.
I agree with Stefan. And that goes for the non-sandbox areas too. What is the point of pushing **library-specific** branches and tags up to the top level?
Like I said some time ago, when the longer svn thread started... It accommodates the most common use case of people going to 1 directory and getting the current version of *all* the sandbox projects. But to give you and idea of the general impact of applying the "branch inside the project dir" generally, say the thread lib needed a branch, like they have now, to work on an experimental version. They might end up with: [svn] boost boost thread trunk branches ex1 libs thread trunk branches ex1 build, docs, example, src, test I know, I'm probably exaggerating for effect. So to take a simpler example. I currently have a branch "Boost_Jam_994" which corresponds to addressing issue #994. I would, under you suggestion, end up with: [svn] boost tools jam trunk (doc,src,test,*) branches Boost_Jam_994 (doc,src,test,*) Which might be fine if you are only interested in getting bjam. But in getting the one Boost checkout you would end up waiting a long time to transfer every variation of Boost code for every library, tool, and random sub-project. What I'm essentially saying, and what KDE seems to be following, is that even though there might be many sub-projects there is only one (or some other small number) project. In our case I'm saying that's "Boost", "Sandbox", and "Website". And under those we follow the mostly suggested trunk, branches, tags arrangement. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo