Re: Subversion history problem

[James Henstridge <james jamesh id au>]

Ross Golder wrote:
> I'm considering a (hopefully) cleaner alternative.
> 
> Assuming that on 2003-09-11, the server clock read 1997-01-04, we should
> be able to calculate (roughly) the drift as a fixed number of
> days/seconds. 

The full list of discontinuities I posted a link to covers more than
just the 2003-09-11 -> 1997-01-04 problem.  That was the only one that
affected the jhbuild module where I discovered that something had gone
wrong.

There were a number of other occasions that the clock was set back to
January 1997, which is most likely reflects the default date set by the
BIOS if the date gets lost when the CVS server got rebooted.

> Around about line 4519 in cvs2svn is a piece of code that checks that
> the previous revision's timestamp is lower than the current revision's
> timestamp, and that the current revision's timestamp is lower than the
> next revision's timestamp and spits out a warning if not. We can add our
> hook here to adjust the current revision's timestamp by our fixed
> amount.

I don't know the cvs2svn code base, so can't say for sure.  Is that part
of the code working with CVS-style per-file revisions, or
Subversion-style tree-wide revisions?

If it is the latter, then is this before or after the revisions have
been sorted?  I did notice that the dates in the Subversion import had
been adjusted, but it looked like the adjustments were to give
increasing time to the revision ordering that it had chosen.

Adjusting the times after sorting would not necessarily help if the
revision sorting was done incorrectly beforehand.

> It might need testing a few times on a couple of the identified modules
> to fine-tune our fixed amount to a resolution of at least a few minutes
> (or until there are no more warnings).

Sure.  The data I provided may help in checking if the solution works:
if there are going to be problems, they'll most likely be visible at one
of the discontinuities.

> Can anyone see why this wouldn't work, or a better/quicker way to do it?
> (pref before I start hacking ;^))

I don't have any better ideas at present, and the only way we will be
able to tell whether your idea works is to give it a go :)

James.
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers