[boost] Re: Moving from CVS to Subversion?

From: troy d. straszheim (troy_at_[hidden])
Date: 2005-02-03 12:10:45

This didn't seem to go through first time, resend...

David Abrahams wrote:

 >> I have already done a couple of cvs->svn conversions for large
 >> projects.  There is a bit of flexibility in how to do it...  the
 >> offer stands to do some test runs and make the svn archives open, to
 >> play with.  This way you can give the OSL guys a properly tweaked
 >> conversion script when you're ready, not just have the archive
 >> dumped through cvs2svn.
 >
 >
 > I never saw such an offer.  If you're offering, for my part, I *think*
 > I accept, and gratefully... but could you elaborate?  I'm not sure I
 > understand the specific details of what you're proposing.
 >

OK, I'll type louder next time...   :)

Main thing I'm offering is elbow grease and a test repository so that 
there are concrete answers to questions like this (I see the thread has 
continued as I write this mail):

Jeff Garland wrote:

 > Sure, but what if the new environment is actually worse in some 
significant
 > way? (yes, more FUD from a fuddy duddy). But the fact is, there won't 
be any
 > going back to CVS once we are converted.

I just thought it would be good to actually beat on an svn repository.

And I have one finished.  But if it's OK I'd like to open it up to just 
library authors or some smaller set of people first, since it's not a 
bandwidth test.   Don't know how to establish what this smaller set 
should be.  Mail me privately?  I can put some scripts into motion on 
the box itself to stress the archive without loading the pipe.

My initial estimate was that the conversion would take a long time to 
get right.  I got a tarball of the CVS repository from sourceforge 
(thanks Rene) and upon trying to put it through cvs2svn this came up:

ERROR: The following symbols are tags in some files and branches in others.
Use --force-tag, --force-branch and/or --exclude to resolve the symbols.
'RC_1_30_0' is a tag in 11 files, a branch in 6513 files and has commits 
in 2605 files.

These conversions have to be done in one pass like a database load, so 
after that error you do Not Pass Go.  In the last project I did it took 
hours and hours to get this all right, there were heaps of those, but it 
turns out that most of the problems I had there don't turn up in boost's 
case.

 >> wonder specifically if boost would be best set up with toplevel 
trunk/branches/tags, or if it would be best to do this somehow per-library
 >
 >
 >
 > Probably a mix would be best.  Release tags need to go at the top
 > level, right?

So the convention with SVN is to put the trunk in "trunk/", tags in 
"tags/", and branches in "branches/", but that is only convention, and 
they came up with that convention presumably because it is 
comprehensible to people are used to thinking in terms of CVS.   cvs2svn 
sets things up like this by default.  But SVN doesn't really know or 
care how this is organized, and it doesn't enforce 
no-committing-to-directories-located-under-tags or anything...  So it 
would be possible to do releases/, release-candidates/, regressions/, 
and miserable-failures/ as well.  Dunno.

When you run cvs2svn w/o tweaking it, all branches and tags that were 
created in the directory tree appear at the top level.  For instance, 
the "branches" directory for a freshly converted boost repository 
contains the following subdirectories:

 > Revision 19694: /branches
 >
 >     * ..
 >     * FUSION_MSVC/
 >     * RC_1_27_0/
 >     * RC_1_28_0/
 >     * RC_1_29_0/
 >     * RC_1_30_0/
 >     * RC_1_31_0/
 >     * RC_1_32_0/
 >     * SPIRIT_1_6/
 >     * SPIRIT_MINIBOOST/
 >     * SPIRIT_RC_1_6_2/
 >     * SPIRIT_RC_1_8_2/
 >     * aix_so/
 >     * alternative_regression/
 >     * bbv1_cross_project/
 >     * better_indirect/
 >     * boost/
 >     * boost++graph/
 >     * boost-graph-library/
 >     * boost_build_v2/
 >     * boost_python_friend_fixes/
 >     * boost_python_richcmp/
 >     * boostify/
 >     * build/
 >     * build-developement/
 >     * build-development/
 >     * build-development-2/
 >     * build-development-gcc-unix/
 >     * build_development-gcc-unix/
 >     * build_for_distribution/
 >     * build_system/
 >     * coding_guidelines/
 >     * coercion_experiments/
 >     * compiler_supported_error_messages/
 >     * conversion/
 >     * cursor/
 >     * data_driven/
 >     * error_handling/
 >     * feature_branch-update_rule/
 >     * fs_review/
 >     * function_signature_patches_1_31/
 >     * function_v2/
 >     * graph_devel/
 >     * graph_devel_1_33_0/
 >     * indexing_v2/
 >     * iter-adaptor-and-categories/
 >     * iterator-adaptors/
 >     * iterator_adaptor_update/
 >     * jam-src/
 >     * jam_src/
 >     * lambda_development/
 >     * lambda_development_during_review/
 >     * langbinding/
 >     * matrix_development/
 >     * more1/
 >     * moved_pointer/
 >     * mpl-development/
 >     * mpl_v2/
 >     * mpl_v2_2/
 >     * mplbook/
 >     * named-args/
 >     * newbpl/
 >     * null_ptr_is_none/
 >     * numerics/
 >     * perforce_2_4_merge/
 >     * perforce_jam_2_4/
 >     * persistence-initial/
 >     * pro7_void_returns/
 >     * python/
 >     * python-v2-dev/
 >     * python_v2_API_restructure/
 >     * ralf_grosse_kunstleve/
 >     * regex-4/
 >     * regex-4-1/
 >     * regex-sub/
 >     * regex5/
 >     * rich_cons/
 >     * rollback/
 >     * sane-testing/
 >     * shared_modules/
 >     * simplify/
 >     * split-config/
 >     * test-development/
 >     * thread-initial/
 >     * thread_dev/
 >     * thread_development/
 >     * tmpw2001-paper/
 >     * to_python_experiments/
 >     * tuples_subnamespace/
 >     * type_traits2/
 >     * uBLAS_pure/
 >     * unit_test_development/
 >     * unlabeled-1.1.1/
 >     * unlabeled-1.1.1.1.10/
 >     * unlabeled-1.1.1.1.6/
 >     * unlabeled-1.1.1.1.8/
 >     * unlabeled-1.1.2/
 >     * unlabeled-1.1.4/
 >     * unlabeled-1.1.6/
 >     * unlabeled-1.1.8/
 >     * unlabeled-1.10.2/
 >     * unlabeled-1.10.4/
 >     * unlabeled-1.11.2/
 >     * unlabeled-1.12.2/
 >     * unlabeled-1.13.2/
 >     * unlabeled-1.14.2/
 >     * unlabeled-1.15.2/
 >     * unlabeled-1.16.2/
 >     * unlabeled-1.18.2/
 >     * unlabeled-1.19.2/
 >     * unlabeled-1.2.2/
 >     * unlabeled-1.2.6/
 >     * unlabeled-1.2.8/
 >     * unlabeled-1.21.2/
 >     * unlabeled-1.23.2/
 >     * unlabeled-1.25.2/
 >     * unlabeled-1.3.2/
 >     * unlabeled-1.3.6/
 >     * unlabeled-1.3.8/
 >     * unlabeled-1.37.2/
 >     * unlabeled-1.37.6/
 >     * unlabeled-1.4.2/
 >     * unlabeled-1.4.6/
 >     * unlabeled-1.5.2/
 >     * unlabeled-1.5.4/
 >     * unlabeled-1.6.2/
 >     * unlabeled-1.65.2/
 >     * unlabeled-1.7.2/
 >     * unlabeled-1.7.4/
 >     * unlabeled-1.8.2/
 >     * unlabeled-1.9.2/
 >     * void_returns/
 >     * wg21_random_proposal/

Which is the same as cvs status -v at the root directory would show you. 
  Maybe a deeper hierarchy in the branch department would be better, or 
a trunk-only import, dunno.  Lot of these don't look useful, a lot of 
them start in development/...   You can't really tell where they were 
rooted, either, of course you don't get that information out of CVS either.

 >
 >> , linked up with svn:externals.
 >
 >
 >
 > Not familiar with that.  Link?
 >

http://svnbook.red-bean.com/en/1.0/ch07s03.html

I can't decide if this is worth thinking about more or not, I can 
already hear people objecting because it would change yet *more* 
variables than just CVS/sourceforge => SVN/OSL, and I thought I'd point 
the capability out for people to chew on a bit.

You can add automatic checkouts of other projects to your project.    So 
"miniboost" or whatever sub-distribution of boost could just be a 
project with a set of svn:external properties that looks something like,

boost/type_traits  http://svn.boost.org/trunk/boost/boost/type_traits
libs/type_traits   http://svn.boost.org/trunk/boost/libs/type_traits
boost/preprocessor http://svn.boost.org/trunk/boost/boost/preprocessor
libs/preprocessor  http://svn.boost.org/trunk/boost/libs/preprocessor
tools              http://svn.boost.org/trunk/boost/tools

or whatever.  When you check out sub-boost, those five directories would 
be populated with source picked out of the middle of boost, and the 
individual "versions" of what gets picked out could vary from boost 
sublibrary to sublibrary, they wouldn't all have to be from the same 
main release of boost.  Parallel to this there could be a mega-boost and 
whatever.  And the svn:externals properties, in that list above, are 
versioned, so you basically have a mapping from a boost release number 
(the version of the sub-boost containing the externals) to a set of 
versions of component libraries.  Which makes you want to think about 
per-library versioning, which for all I know might have already been 
tried and is Considered Harmful.    This could conceivably make little 
releases easier to get out the door and little distributions easier to 
create...   just as conceivably could create total mayhem...

troy d. straszheim