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.
wonder specifically if boost would be best set up with toplevel
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. 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