Douglas Gregor wrote:
Reading about Mono's switch to svn made me wonder if some of these problems are because we're trying to use our cvs tricks with svn, when those tricks have only become habit to get around cvs's limitations.
Alan Gutierrez wrote:
I'm not sure where to chime in, but I was just attempting to check out one of the Jakarta Commons sub-projects.
Their directory structure is such that, if you want to checkout all of commons, you cant simply checkout trunk/commons, because you'll checkout every branch, ever.
It looks like this:
/huge-library-project /library-1 /trunk /BRANCH_1 /BRANCH_1_1 /BRANCH_1_2 ... /library-2 /trunk /RELEASE_2_0 /RC_2_0 /RC_2_1 ... ...
Might be easier to manage a specific library, but it's hard on the non-commiter that want's to build from source control.
In any case, I hope you'll consider carefully, the project structure when you move away from the tag based system in CVS.
SVN accomodates this structure quite nicely. In the spirit of considering the project structure carefully, here's a few thoughts. Assume that you have your libraries broken up as in the jakarta example above. boost would look something like this: /boost /boost /shared_ptr /trunk /branches/v1.0 /branches/v1.1 /type_traits /trunk /branches/v1.0 /branches/some_other_branch /libs /shared_ptr /trunk /branches/v1.0 /type_traits /trunk /branches/v1.0 /branches/some_other_branch /tools /trunk /branches/v1.0 Now that kind of looks like a nightmare, but svn makes it pretty easy to handle. A checkout of the trunk should assemble the trunks of each sublibrary locally in such a way that immediately after the checkout, you're ready to bjam without additional work. Named releases should do something similar, but with various releases of various sublibraries. Subversion supports this with "externals", simply a mapping from local directory to some other directory back in the repository, such that when you check out the directory containing the externals, svn automatically does the specified checkouts. So the trunk externals for the test case would be: boost/shared_ptr http://svn.boost.org/boost/boost/shared_ptr/trunk libs/shared_ptr http://svn.boost.org/boost/libs/shared_ptr/trunk boost/type_traits http://svn.boost.org/boost/boost/type_traits/trunk libs/type_traits http://svn.boost.org/boost/libs/type_traits/trunk tools http://svn.boost.org/boost/tools/trunk which would leave you looking at something that was pretty close to what boost currently looks like. To see a small test case, click around how things are organized at http://svn.resophonic.com/otherboost. You won't be able to see the externals properties in a web browser, but if you check out the trunk svn co http://svn.resophonic.com/otherboost/trunk you'll see that your directories get populated with the trunks of the sublibraries. run "svn propedit svn:externals ." to see the actual list. in any of those sublibraries you can switch from version to version by changing the list you see in propedit, or by cding to the directory and using "svn switch". Can't see exactly how this would have affected Doug Gregor's life in the graph_devel case he mentioned. If you "svn co" the other directories, like http://svn.resophonic.com/otherboost/v1.0, you'll see that the branched versions of the sublibraries get pulled down instead of the trunks. http://svn.resophonic.com/otherboost/shared_ptr-only links in only the shared_ptr, a subdistribution example. I mentioned this in a previous thread, since I now have an example together and the topic of doing things differently than CVS has come up since then, I wanted to reintroduce the idea. Subdistributions of boost would be easy to assemble: leave out certain libraries. In CVS, if somebody commits something to the head of their library that breaks stuff boost-wide, in order to fix the head, you have to check out the old version, merge it back in to the head and commit it, perhaps after branching off the changes that broke things, if they are to be reintroduced later (I'm thinking of the recent boost.test stuff...); With this externals scheme, one just changes a couple lines in the trunk's svn:externals properties to refer to an older version of the problematic sublibrary. There is a certian difference in visibility here with respect to what branches exist in the repository and how many concurrent "threads" of development there actually are: they are laid out for you in each sublibrary. By contrast, The "head" isn't just all the source that happens to be associated with some common identifier in source control, it is instead the collection of branches of individual sublibraries that work the best together and have collectively the highest revision number. Additional levels of abstraction, all that. Just FWIW troy d. straszheim