[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: cvs2svn.py in version 6411

From: <kfogel_at_collab.net>
Date: 2003-07-10 05:14:54 CEST

Mike Wilcox <mike@trouble.org.uk> writes:
> As an aside, I was a little conerned when I saw this kind of thing
> in the output:
> <<< Started new txn, based on original revision 38
> * adding path : tags/T_ALL_INITIAL_FILES ...COPIED... done.
> * deleting path : tags/T_ALL_INITIAL_FILES/partial-prune ... done.
> * deleting path : tags/T_ALL_INITIAL_FILES/single-files ... done.
> The tag T_ALL_INITIAL_FILES only seems to be used by the "project"
> proj, so, while deleting paths related to 2 of the other projects (why
> not all other projects?) isn't harmful, I did wonder why it was even
> necessary.

Because if we didn't delete them, they'd be included in the tag, which
would be incorrect :-). (In other words, the copy that created the
tag picked up a bit too much, so we have to remove the extra stuff.
cvs2svn is all about finding semi-minimal sets of copies and deletes
that will create tags and branches correctly.)
> The problem is almost certainly my understanding about the way in
> which your process works through the order a CVS repository has been
> created. If you think this is right, it's enough for you to say "its
> right".

"It's right."

> 1) When converting our CVS repository, I want to split it into 3 SVN
> repositories, which means I create the repositories first, then loop
> for each subproject in CVS. This was also to try to keep the tags &
> branches separate for the different projects.
> Conversion of the first project into each svn repository works fine,
> but the subsequent ones fail because the loader, prior to creating
> 'trunk/<proj>', tries to re-create the 'trunk' directory - which now
> already exists.

I'll need a small, concrete example to understand what this means, I
think. There are too many possible interpretations. For example, I
don't know what you mean by "Conversion of the first project into each
svn repository works fine." At first I thought you were putting each
project in its own repository, but now it sounds like you're trying to
put trunk in one repos, branches in another, and tags in a third? Or
maybe you're using the word "repository" to mean "subdirectory within
a repository"?...

> 2) Back to this problem... As a workaround to 1), I adjusted my
> conversion process to create the SVN repos, then loop through the CVS
> repositories, but using the --trunk, --branches and --tags options to
> control placement into something akin to the "old"
> hierarchy. Afterwards, I later move the created structures back into
> the "new" hierarchy of "trunk/<proj>" etc.
> It seems that the command option for --branch is causing the
> problem. This doesn't produce any tags:
> $ ../cvs2svn.py -s svnrepos --trunk=<proj>/trunk
> --branches=<proj>/branches --tags=<proj>/tags --no-prune
> ../cvsroot/<proj>
> But these do:
> $ ../cvs2svn.py -s svnrepos --trunk=<proj>/trunk --no-prune
> ../cvsroot/<proj>
> $ ../cvs2svn.py -s svnrepos --trunk=<proj>/trunk --tags=<proj>/tags
> --no-prune ../cvsroot/<proj>
> So, similar to your suggested command at the top, the following fails:
> ../cvs2svn.py --create -s svnrepos --trunk=test1/trunk
> --branches=test1/branches --tags=test1/tags ../test-data/main-cvsrepos/
> Hopefully, this will help you fix it. It's beyond my python knowledge
> (or cvs2svn knowledge) to attempt a patch.
> Back to you later on a test case for the original problem :-)

Oh my goodness. I think what you're trying may be beyond cvs2svn's
capabilities right now. I'm interested in supporting it eventually,
but right now it's more important to fix bugs in the core
functionality. One of the current issues is that cvs2svn needs
documentation -- and if it had docs, they'd probably say not to try
passing multi-component paths as arguments to --trunk, --tags, etc. :-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 10 06:07:04 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.