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

Re: cvs2svn (6485) chooses wrong revision to create branch?

From: Mike Wilcox <mike_at_trouble.org.uk>
Date: 2003-07-22 01:22:14 CEST

kfogel@collab.net wrote:

>Mike Wilcox <mike@trouble.org.uk> writes:
>
>
>>$ python cvs2svn.py -s repos --no-prune cvsroot/<project>
>>...
>><<< Started new txn, based on original revision 1559
>> * editing path : branches/branch2/<blah>/file1 ... done.
>> * editing path : branches/branch2/<blah>/file2 ...
>>svn: Filesystem has no item
>>svn: file not found: transaction `17b', path `branches/branch2/<blah>/file2'
>>
>>
>
>This is almost certainly issue #1421 (whose cause is known now, I'm
>writing a regression test currently & then will fix).
>
So I see. I'm still trying to understand your explanation in the
comments of 1421, to see if I can see what's happening :-)

>> From cvs2svn-dump, the major points I can see leading up to this event are:
>>
>>rev 1459: source of branch1
>>rev 1469: creation of 'branches/branch1'.
>>rev 1544: source of branch2
>>rev 1556: creation of 'trunk/<blah>/file2'
>>rev 1558: first creation of 'branch2', from trunk at 1544.
>> Some deletion & addition/changes, but nothing to file2.
>>rev 1559: attempt to edit 'branches/branch2/<blah>/file2'.
>>
>>The CVS Repository has a revision 1.1 of file2, whose timestamp
>>matches (-ish) the rev 1556 creation, and a rev 1.1.2.1 whose
>>timestamp matches the update in 1559. The definition of the symbol for
>>branch2 is 1.1.0.2. I don't think cvs2svn has lost any revisions
>>inbetween.
>>
>> From this, I have some suspicion that cvs2svn has created the copy of
>>branch2 from the wrong place - it should have been at least rev 1556.
>>
>>
>
>The issue isn't whether the branch as a whole was copied from 1556,
>but whether file2 was correctly spliced in from 1544. However, note
>that a parent (or grandparent, etc) of file2 could have been copied
>from an earlier revision. Did you check for that?
>
When you ask about a (grand-) parent to file2, do you mean an older
version of file2 (which is what I assume you mean) or do you mean a
(grand-) parent directory?

If it's the first case, file2 didn't exist in the repository anywhere
until 1556 - that was the match to cvs-revision 1.1, and was rightly
created on the trunk. The edit that goes wrong is in trying to update
1559. which matches CVS revision 1.1.2.1.

Note:
1544 was committed: "Mon Oct 7 19:43:30 2002".
File2, rev 1.1 was created "2002.10.09.18.31.44", and committed in 1556
at "Wed Oct 9 19:31:44 2002".
The first commit on branch2 was "Thu Oct 10 11:33:49 2002".
Symbol <branch2> in file2 is specified to be: 1.1.0.2
File2, rev 1.1.2.1 was created "2002.10.10.10.38.31", and committed in
1559 at "Thu Oct 10 11:38:31 2002"

(Hopefully the hour's difference between CVS and SVN is explained by
daylight saving at the time!)

I don't believe we did anything "funny" with the branches or tags
anywhere - that is, we only made each tag/branch once, in each case from
the root of the project. It thus strikes me that the best place cvs2svn
could have found for the place to copy from, for the entire branch,
ought to have been 1556.

At any rate, there was no possible version of file2 around at 1544.

If the second case, then <branch2> is only created in 1558. There is no
place higher in the directory hierarchy that could act as a grandparent,
and no creation of the file inside transaction 1558.

>>However, the CVS repository is huge, and I haven't been able to prune
>>it down to something that will be able to help identify the cause of
>>the problem. And at 150 minute run-time, it's too much for
>>trial-and-error :-(
>>
>>Any clues as to how I could add extra debugging to cvs2svn, or how to
>>selectively whittle down the CVS repository?
>>
>>
>
>I just put in print statements :-).
>
Ah. Reminds me of the old engineer's invoice:

To: Applying hammer: $1.00
To: Knowing where to apply hammer: $99.99

In this case, the toolbox requires a goof example to copy - so I have
your debugging prints from 1421 applied :-)

> You might want to just wait until
>current issues are fixed and just try again, though, especially #1421.
>

I'm sure that's exactly what the net result will be :-) However, I like
to know what's going on under the bonnet.

Cheers,

   Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 22 01:23:12 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.