KDE is also a large project with separate subprojects. I thought it might be a good idea to look at their structure. Here are some instructions: http://websvn.kde.org/tags/KDE/3.90.1/kde-common/svn/svn_instructions.txt?revision=660709&view=markup The instructions points to the tutorial: http://developer.kde.org/documentation/tutorials/subversion/index.html Here is the repository: http://websvn.kde.org/ Browsing the tags, I find the main releases of KDE, but I don't easily see the version numbers of the underlying projects. This baffles me slightly. But it seems to work well (doesn't it?). Regarding boost sandbox: I think it is good to be able to checkout one directory to get the trunk of everything. I.e. The subprojects shall not contain separate trunk/branches/tags. 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. /$ (disclaimer: I'm new to both Boost and Subversion)
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
participants (2)
-
Henrik Sundberg -
Rene Rivera