Open avar opened 14 years ago
I commented out that confess which yields this:
commit 62f777779008b5c97e2295398be7a472ff85e0dd
Author: (no author) <(no author)@example.com>
Date: Thu Nov 20 13:12:41 2003 +0000
This commit was manufactured by cvs2svn to create branch 'newfeatures'.
And:
git snerp-into (branch-newfeatures) $ git show 62f777779008b5c97e2295398be7a472ff85e0dd | grep DateFormatter
git snerp-into (branch-newfeatures) $
I.e. it seems harmless to just allow this and carry on.
Another cvs2svn commit; r2606 also causes trouble:
/branches/REL1_2/phase3/config (added)
/branches/REL1_2/phase3/config (from /trunk/phase3/config:2604) (added)
git log phase3/config
on the tag-REL1_2_0rc2
branch shows that there are several commits to /index.php
in that directory already:
75f61f1 Initialize log pages; bow out quick if dir not writable. Installation now seems to be pretty much functional!
cbde3f6 Initialize messages.
e7b606a Create sysop account on new wiki creation.
1eb3135 Add database creation to in-place installer, plus a couple fixlets.
fdc2430 Experimental in-place installer.
And another one: r2833:
1621 GIT) already on branch tag-REL1_2_0
can't remove nonexistent directory phase3/rdf at lib/SVN/Dump/Replayer/Git.pm line 283
SVN::Dump::Replayer::Git::on_directory_deletion('SVN::Dump::Replayer::Git=HASH(0x10fe720)', 'SVN::Dump::Change::Rmdir=HASH(0x7ff2eb707b00)', 'SVN::Dump::Revision=HASH(0x15772718)') called at lib/SVN/Dump/Replayer.pm line 112
SVN::Dump::Replayer::on_revision_done('SVN::Dump::Replayer::Git=HASH(0x10fe720)', 2833) called at /usr/local/lib/perl/5.10.1/Class/MOP/Method/Wrapped.pm line 54
Class::MOP::Method::Wrapped::__ANON__('SVN::Dump::Replayer::Git=HASH(0x10fe720)', 2833) called at /usr/local/lib/perl/5.10.1/Class/MOP/Method/Wrapped.pm line 89
SVN::Dump::Replayer::Git::on_revision_done('SVN::Dump::Replayer::Git=HASH(0x10fe720)', 2833) called at lib/SVN/Dump/Walker.pm line 114
SVN::Dump::Walker::walk('SVN::Dump::Replayer::Git=HASH(0x10fe720)') called at ./snerp line 150
And another one: r3144:
1811 popdir /home/avar/g/snerp-vortex
1811 REP) doing: file_deletion tags/REL1_2_4/phase3/includes/SkinSmarty.php
1811 REP) entity:
1811 REP) status: is not entity
1811 REP) calling method on_file_deletion
1811 pushdir /tmp/snerp-into
1811 GIT) already on branch tag-REL1_2_4
can't remove nonexistent file phase3/includes/SkinSmarty.php at lib/SVN/Dump/Replayer/Git.pm line 372
SVN::Dump::Replayer::Git::on_file_deletion('SVN::Dump::Replayer::Git=HASH(0x10fe720)', 'SVN::Dump::Change::Rmfile=HASH(0x158bb078)', 'SVN::Dump::Revision=HASH(0x158be2e0)') called at lib/SVN/Dump/Replayer.pm line 112
SVN::Dump::Replayer::on_revision_done('SVN::Dump::Replayer::Git=HASH(0x10fe720)', 3144) called at /usr/local/lib/perl/5.10.1/Class/MOP/Method/Wrapped.pm line 54
Class::MOP::Method::Wrapped::__ANON__('SVN::Dump::Replayer::Git=HASH(0x10fe720)', 3144) called at /usr/local/lib/perl/5.10.1/Class/MOP/Method/Wrapped.pm line 89
SVN::Dump::Replayer::Git::on_revision_done('SVN::Dump::Replayer::Git=HASH(0x10fe720)', 3144) called at lib/SVN/Dump/Walker.pm line 114
SVN::Dump::Walker::walk('SVN::Dump::Replayer::Git=HASH(0x10fe720)') called at ./snerp line 150
I worked around all of the above with this commit to my branch. Just turning the relevant confess
into cluck
. This doesn't seem to have affected the quality of the conversion, the history still makes sense.
I want to leave these fatal until I understand why snerp is trying to create things that already exist---and remove things that don't. Patching around the fatalities seems like sweeping issues under the carpet.
Sure. That particular branch is just something I'm doing to try to force the issue as an experiment, sometimes with lossy results, as seen in the recent s/confess/cluck/g
commit.
However the specific issues/change in this bug is something that I think makes sense. As far as I can see SVN does not enforce any sanity for revisions, so you really can have stuff like:
r1: add foo.txt
r2: add foo.txt
r3: amend foo.txt
I.e. it seems svn just does these sort of issues in the porcelain, not the plumbing. Maybe this issue is isolated to cvs2svn but I'm guessing there are a lot of repos out there with similar broken but harmless revisions.
Per discussion in irc.perl.org #snerp, this may actually be another case of poor branch relocation. The foo.txt isn't actually being added twice... the second one seems to be a branch creation.
snerp is crashing again on the MediaWiki repository. I'm running my latest Git revision (with your patches) and have tried both CPAN, your GitHub and the temporary tarball you gave me, all with the same results:
This is the last revision:
Which is this revision: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/2024
/trunk/phase3/includes/DateFormatter.php (added)
Then the one that's failing is this one: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/2025
It also adds DateFormatter.php:
So cvs2svn is creating a branch here, and it looks like it's creating a duplicate file in the process of doing so.