I think it could be better to have trunk/tags/branches on the topmost directory level, and to use trunk instead of devel. I would also like to see how libraries could have their own release-cycles, with the major Boost-releases just picking appropriate library-releases. /$ 2007/5/30, Rene Rivera <grafikrobot@gmail.com>:
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.
-------- Original Message -------- Subject: Re: [boost] Subversion structure in KDE Date: Sun, 27 May 2007 17:54:20 -0500 From: Rene Rivera <grafikrobot@gmail.com>
Henrik Sundberg wrote:
KDE is also a large project with separate subprojects. I thought it might be a good idea to look at their structure. [snip] Here is the repository: http://websvn.kde.org/ [snip] How about a trunk with the two subdirectories Boost and Sandbox? The Boost directory would contain libraries that are to be part of the next official Boost release, and the Sandbox other libraries.
If I'm understanding you, and the KDE docs, correctly, what you want is something like(**):
[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)
That seems like a reasonable arrangement to me. It has the beauty of being easy to explain, and it's not too far off from what we have now. The one drawback I can see is that one common case, of updating boost/stable and boost/devel can't be done in one go. But I think that's a reasonable aspect to give up (not that we had it in the first place) since hopefully working with both at the same time will be an infrequent task.
(**) I'm ignoring the website tree because it's not the same kind of beast. Since it only has to deal with two versions, and doesn't need tags.
-- -- 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost