cscvs breaks when a cvs merge creates a file

Bug #120977 reported by Michael Hudson-Doyle
24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad CSCVS
Fix Released
High
Michael Hudson-Doyle
NUnit V2
Fix Released
High
Unassigned

Bug Description

This affects many imports, as can be seen on the https://help.launchpad.net/VcsImportRequests page.

It's something to do with 'dead' revisions. When a file is created on a branch, it gets an entry in the log of the MAIN branch but with a 'dead' revision state, more commonly seen when a file is 'cvs rm'ed. Then, when this branch is merged to MAIN, cvcvs freaks, with an exception like:

    On changeset MAIN.7669 ValueError: attempt to patch non extant file : docs/design/draft-missing-plugins.txt

This link is very relevant, and gives a recipe for the cscvs test suite:

http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Branching_and_merging#Merging_can_add_or_remove_files

Revision history for this message
David Allouche (ddaa) wrote :

Confirming, High importance as it is by far our main cause of new CVS import failures.

Changed in launchpad-cscvs:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I can't see any way at all this can be completed before the code import transitions, unless we stop caring about the deadline we set ourself for that. A reasonable estimate is that we'll get to this in 2008 :/

Changed in launchpad-cscvs:
assignee: nobody → Michael Hudson (mwhudson)
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Well, just so people know, this bug is a bit more complicated than it appears, and has defeated my attempts at a simple test case. It seems something to do with incremental vs full updates -- a complete import will succeed where an incremental one will fail. Still digging.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

The linked branch contains a tentative fix. It works, as far as I can tell, but the performance is all the wrong way up. I should be able to polish up a better fix next week.

Changed in launchpad-cscvs:
status: Triaged → In Progress
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :
Changed in launchpad-cscvs:
status: In Progress → Fix Committed
Changed in nunit-2.5:
importance: Undecided → High
status: New → Confirmed
status: Confirmed → Fix Committed
Changed in launchpad-cscvs:
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed
Changed in nunitv2:
status: Fix Committed → Fix Released
Changed in launchpad-cscvs:
status: Fix Committed → Fix Released
Revision history for this message
Christian Reis (kiko) wrote :

This is still happening here at https://code.edge.launchpad.net/~vcs-imports/po4a/head -- I've gone ahead and created a new import at https://code.edge.launchpad.net/~kiko/po4a/trunk-new to figure out if it's broken even for a brand new import of that branch. If that doesn't fail then it seems that either the new code isn't being used for the head import, or that the fix didn't fix it for all situations.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Although the traceback is certainly similar, that's not the same bug -- the "non extant" file being patched was not created by a merge. In fact, that file seems to have an entirely boring revision history, so I don't know what's going on here at all (maybe a mv in the CVS repo?). I'm interested to see if the new import succeeds!

Actually looking a bit more, it looks like someone _copied_ the ,v file in the CVS repo -- I expect the new import will be fine.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.