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-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
