Boost logo

Boost :

From: Michael Caisse (boost_at_[hidden])
Date: 2007-08-26 02:37:01

Beman Dawes wrote:
> I've set up a couple of my development branches in SVN. See the
> attached screenshot of the Boost.System branch.
> It wasn't entirely clear how to cope with the fact that typical boost
> libraries have several sections. For example, Boost.System has one
> header in boost-root/boost, other headers in boost-root/boost/system,
> and then the rest of the library in boost-root/libs/system.
> I've currently got the filesystem branch organized like this:

> In other words, organized the sub-tree under
> /svn/boost/branches/libs/system exactly the same way the trunk is
> organized. That might be easier for others to understand. I also
> wonder if it has any advantages as far as various SVN operations go.
> Opinions?
> --Beman
Let me start with, I'm no librarian and most of my knowledge comes from and a lot of trial under various sized projects,
some of which have many libraries, frameworks and components scattered all

Branches are a nice place to do work within the *system*. You can have history
with your changes, collaborate and have that fuzzy feeling inside that when
your drive crashes that your work is still somewhere. The high level branch
directory structure is important for guiding developers where to place and
find work, but the lower level structure is not very important. In other
words, I think the layout (.../branches/libs/serialization) has been defined
at the appropriate level. I would not provide structure beyond there. Perhaps
some use case examples would be helpful.

For instance:

If I am making changes to "system" based on .../svn/boost/trunk I would
do the following ( note: the Improving Practices document has users start with
the stable .../boost/branch/release location but if your merge destination is
the trunk and a dependency (prerequisite) is modified in the trunk, you will need
to work that out in the trunk before changes are moved to the release branch. I'm
still thinking this out. )

1. Start with a clean check out of trunk. This is the basis for my changes and
   therefore it is what I need to make sure is "up-to-date" with other possible
   developer changes at various check points. Since it is my responsibility to
   merge back to the trunk and have stability, I will want to make sure that I'm
   keeping up with changes to the trunk. Notice, I did not copy the whole boost
   trunk to a branch because that just makes things more difficult when staying
   in sync with the trunk. A svn copy is inexpensive; however, it should not be
   confused with a symbolic link. Changes made to the trunk after the branch copy
   would have to be merged from the trunk into your branch. Yuck.

   svn co

2. Copy within svn the directories (or files) I want to modify to a branch. For
   my example it might look like this:

   svn mkdir
             -m "Making a branch director for my system work"
   svn cp

          -m "copy boost/system into working branch"

   svn cp

          -m "copy libs/system into working branch"

   Notice that I copied into a unique directory within branch/libs/system. This
   would allow others to make changes to system while using the
   .../boost/branches/libs/system location also. As you can see I don't
   really care that the structure doesn't look the same as the standard boost
   directory layout. The switch will handle that problem.

3. Switch your working areas of the trunk checkout to the branch copy you just
   made. Subversion operations will then be on the branch location for the switched
   directories (files) and the trunk for everything else.

   cd <your new checkout of the boost trunk>
   cd boost/system
   svn switch
   cd ../../libs/system
   svn switch

4. Work as normal. I'm version control happy and believe numbers are free so I
   like to check in often. Sometimes I just checkpoint changes that don't even
   compile. I figure it is my branch and the tool is there to help me.

   Occasionally I will check for changes on the trunk that I can "svn update"
   to make sure I'm in sync with the trunk.

5. Eventually I'm done developing and everything works great. I then "svn update"
   to ensure there are no more trunk changes. At this point I know that I'm in sync
   with the trunk so doing a merge into the trunk is a simple operation.

I apologize if this was just common knowledge noise and I've wasted both your
time and bandwidth. I don't have access to boost svn (write) so I wasn't able
to try this out. There may be issues with the https access that I haven't
taken into account. The steps are what I follow daily, the commands may be
off. Your mileage may vary.


Michael Caisse
Object Modeling Designs

Boost list run by bdawes at, gregod at, cpdaniel at, john at