Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk