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: <snip>
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 http://svnbook.red-bean.com/ and a lot of trial under various sized projects, some of which have many libraries, frameworks and components scattered all around.
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 https://svn.boost.org/svn/boost/trunk 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 https://svn.boost.org/svn/boost/branches/libs/system/caisse -m "Making a branch director for my system work" svn cp https://svn.boost.org/svn/boost/trunk/boost/system https://svn.boost.org/svn/boost/branches/libs/system/caisse/boost_system -m "copy boost/system into working branch" svn cp https://svn.boost.org/svn/boost/trunk/libs/system https://svn.boost.org/svn/boost/branches/libs/system/caisse/libs_system -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 https://svn.boost.org/svn/boost/branches/libs/system/caisse/boost_system cd ../../libs/system svn switch https://svn.boost.org/svn/boost/branches/libs/system/caisse/libs_system 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 -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com