Re: Subversion history problem
- From: Ross Golder <ross golder org>
- To: James Henstridge <james jamesh id au>
- Cc: gnome-infrastructure gnome org, "Guilherme de S. Pastore" <gpastore gnome org>, GNOME Hackers <gnome-hackers gnome org>
- Subject: Re: Subversion history problem
- Date: Thu, 04 May 2006 17:57:40 +0700
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.
>
Thanks to the cvs2svn hackers, the latest version of cvs2svn now works
with python2.2. So, armed with the latest cvs2svn, and my
hack^w^w^w^wpatch intended to address the clockskew problem, I have
re-run the full import once again:
http://svn.gnome.org/migration/
What I could do with is a hand identifying whether my patch has fixed
the problem. I have spot checked a couple of the problems in James's
'cvs-time-problems' link and them look to me to be OK in the latest run.
However, I would appreciate a second opinion, and some more thorough
checks (which I don't currently have time to do myself).
If anyone has some spare time and can help, please reply to this post
with a report of your findings.
If this has solved it, we might finally be able to start thinking about
re-scheduling a live migration :)
Thanks,
--
Ross
> 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.
>
> Care needs to be taken with this approach though to make sure that the
> date changes are synchronised, otherwise it can result in changesets
> being split.
>
> I don't currently have any suggestions for automated ways of fixing the
> problem.
>
> James.
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]