Re: Subversion history problem

[Ross Golder <ross golder org>]

On พฤ., 2006-02-16 at 14:16 +0800, James Henstridge wrote:
> James Henstridge wrote:
> 
> >Hi Ross,
> >
> >I was looking through the history of the imported version of jhbuild,
> >and it seems that the order of the changesets is incorrect.
> >  
> >
> [snip]
> 
> At the request of Guilherme, I put together a script to detect
> occurrences of clock skew in the existing CVS history.  The results can
> be seen here:
> 
>   http://www.gnome.org/~jamesh/cvs-time-problems
> 
> Each entry in this log indicates a revision of the file whose date that
> is earlier than the previous revision.  Note that this is not a complete
> list of problem revisions.  For each discontinuity there may be multiple
> revisions with bad dates before the clock was corrected.
> 
> There are 1245 affected files spread over the following 98 modules:
> 
> acme, atomix, Attic, balsa, bonobo-activation, bonobo-backup, dashboard,
> dia, dr-genius, eider, eog, epiphany, evolution, evolution-data-server,
> gal, galeon, gb, gedit, gegl, gernel, gftp, ggv, ghex, gill, gimp,
> gimp-freetype, gimp-web, glib, gnet, gnome-applets,
> gnome-control-center, gnome-core, gnome-debug, gnome-desktop,
> gnome-games, gnome-games-deprecated, gnome-guile, gnome-i18n,
> gnome-icon-theme, gnomeicu, gnome-media, gnome-panel, gnome-pilot,
> gnome-python, gnome-session, gnome-utils, gnome-vfs, gnomeweb-wml,
> gnumeric, goffice, gok, grapevine, gswitchit, gthumb, gtk--, gtk+,
> gtk-book, gtkhtml, gtk-reference, gtranslator, gucharmap, guppi3,
> gxsnmp, _lgp_test, libbonobo, libbonoboui, libgnomecanvas, libgnomedb,
> libgnomeprint, libgnomeprintui, libgnomeui, libgtop, libgtop-backends,
> libole2, librsvg, libxml2, libxslt, mango, mc, medusa, mrproject,
> nautilus, oaf, ooo-build, openoffice, ORBit2, pan, pango-web, pyIDL, rc,
> rcd-modules, rp3, sodipodi, sound-juicer, stickynotes_applet,
> sun-patches, web-devel-2, zenity
> 
> The conversion process is likely to result in corrupted history for any
> of these modules.
> 
> Guilherme's suggestion for fixing the problem was to manually edit the
> RCS files directly to provide increasing commit times, which should
> prevent the cvs2svn bug from being triggered.  He was able to do this
> fairly easily for the "jhbuild" module, since only a few files were
> affected.
> 

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. 

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.

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).

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

--
Ross