From: troy d. straszheim (troy_at_[hidden])
Date: 2005-02-05 19:04:35
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:
> 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:
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
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.
troy d. straszheim
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk