Re: [boost] SVN repo structure...

From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2007-06-01 01:29:53

On Wednesday 30 May 2007 22:29:05 Rene Rivera wrote:
> [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)

boost/stable would contain a copy of boost/tags/boost_1_34_0 currently and 
both would be equal to what you get when you download the tarballs/zips, 
right?

Further, if I want to finally finish the port to Windows CE, admins could 
create a branch and assign commit-rights to me (I don't have them otherwise) 
so I don't have to use my company's private repository and so that everybody 
can see and contribute. When the code has been thoroughly tested, the changes 
can be merged into boost/devel. Is that one of the goals?

>     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)

I wonder what we need the sandbox for? I would say that it's for separated 
development of features. However, for that I could as well use a branch like 
above that includes a complete Boost tree. This wasn't the case for CVS, 
where copying files around had significant overhead IIRC, but with Subversion 
you get cheap copies.

Now, if someone wants to test then new lib, they simply 'svn switch' their 
working copy from boost/devel to boost/branches/some-new-lib and run their 
buildscripts. IOW, having a complete tree will reduce the barrier to testing 
it (theoretically, the only changes are that one library and all other code 
will remain unaffected) and will also reveal when library experimenters fail 
to regularly merge changes from boost/devel to their tree, which in the other 
direction affects the ability to merge their new library to boost/devel.

Of course, this requires some discipline:
People need to know which version their branch is based on. Further, they need 
to know which of the possible changes to their base have been merged. The 
first can rather easily be determined from the logs, but the second requires 
some manual work because Subversion doesn't yet feature merge tracking (due 
in version 1.5 or 1.6).

Example:
I'd do my above port based on 1.34 first, simply because that one is well 
tested and stable. Later, I would split off a development version and merge 
the changes between 1.34 and the current version into it, to prepare for the 
changes to be merged back. Once the changes are merged back, the development 
branch could be deleted again.

> 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.

I don't think that updating boost/stable happens often, but that of course 
depends on what you want to put there. Can you tell us what you want there?

Uli