[boost] Re: Was [RE: Moving from CVS to Subversion?] Now is "Subversion experiences from the field"

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:
> 
>     /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