Ticket #37 (closed defect: wontfix)

Opened 7 years ago

Last modified 7 years ago

problems converting cvs -> bzr in presence of bad non-ascending dates

Reported by: james@… Owned by: lele
Priority: major Milestone: VersionOne
Component: cvs Version: 0.9
Keywords: Cc:

Description

Using tailor-0.9.20 and bzr-0.7, I was trying to convert a project from CVS to bzr.

It seems that the clock on the CVS server went crazy for a short period in 2003, causing a couple of commits to have dates in 1997 (before the project started). This seems to have tripped up tailor a bit in deciding where the history should start.

Manually editing the RCS files seems to make the commit dates ascending again seems to have fixed the problem, but it would be nice if tailor could cope with these sort of problems.

The code in question is free software, so I can provide a tarball of the CVS repo (about 640kb) if that'd help.

Change History

comment:1 Changed 7 years ago by Lele Gaifax

  • Component changed from tailor to cvs

Uhm, surely tailor cannot be a panacea for every shortcoming of cvs, even if it's just great if it can reduce those at a minimum.

Anyway, I cannot see how tailor could reorder and reset the date: there's a chicken and egg situation, where tailor uses the timestamp of changes to group them in a single changeset, so the order is fundamental just to get at them.

But what's the problem? Was tailor unable to bootstrap the project, or what? Could you attach the log, or a better description of the issue?

comment:2 Changed 7 years ago by james@…

Here's a viewcvs URL showing the date screwup.

 http://cvs.gnome.org/viewcvs/jhbuild/modulesets/gnome24.modules?view=log&logsort=cvs#rev1.60

rev 1.59 - 2003-09-09 rev 1.60 - 1997-01-04 rev 1.61 - 1997-01-04 rev 1.62 - 2003-09-12

Tailor seemed to correctly break the CVS history into changesets (even though the dates aren't sequential, the changes in each changeset still share the commit date).

On my initial run (before editing the RCS files to correct the dates), the problems I saw were:

  • the first of these 1997 changsets were picked as revision 1
  • Tailor bombed out part way through, when it tried to tell bzr to delete a file that it didn't know about (I assume that it skipped the changeset where the file originally got added).

After correcting the dates in the RCS files, the conversion process went off without a hitch.

It would be nice if Tailor could either support bad CVS history like this, or error out early when this condition is encountered.

comment:3 Changed 7 years ago by james@…

The problem seems to be the sort() call in ChangeSetCollector?.iter, which sorts on (timestamp, author, changelog).

To correct the problem, the sort algorithm would need to be updated. This could be done using a topological sort based on the following partial order: if a changeset creates revision X for a given file, it must come after changesets with lower revision numbers for that file. If there is ambiguity, the changeset timestamp can be used as a tie breaker.

Alternatively, the problem can be detected by sorting the changesets as is done right now, and then check for cases where the revision numbers are not increasing as you go through the changesets.

comment:5 Changed 7 years ago by lele

  • Status changed from new to closed
  • Resolution set to wontfix
  • Summary changed from problems converting cvs -> bzr in presence of bad non-ascending dates to problems converting cvs -> bzr in presence of bad non-ascending dates

This is a bit too generic. Please, reopen the ticket attaching a config to reproduce the problem against a public CVS repository, or attach a simple one that exploits the problem.

comment:6 Changed 7 years ago by kkkkoaaa

  • Summary changed from problems converting cvs -> bzr in presence of bad non-ascending dates to problems converting cvs -> bzr in presence of bad non-ascending dates

Keep a good job up!  http://quick-adult-links.com

comment:8 Changed 7 years ago by lele

  • Type set to defect
  • Summary changed from problems converting cvs -> bzr in presence of bad non-ascending dates to problems converting cvs -> bzr in presence of bad non-ascending dates

Spammer works against our freedom. Squash 'em.

Note: See TracTickets for help on using tickets.