Bug: git-svn fails on Mediawiki SVN repo r2992

Bug: git-svn fails on Mediawiki SVN repo r2992

[Thomas Bleher]

There is some problem between git-svn (v1.4.4.1.gad0c3) and MediaWiki
SVN when cloning their repo.

I just did
$ git-svn init http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3
$ git-svn fetch -r 2991:3122
and git-svn went into an endless loop, repeatedly downloading and adding
the same files from r2992 over and over again.

The bad revision can be viewed here:
http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=2992
It adds ~1000 files (mostly small images).
I can check out this revision just fine using the svn command line
client.

I found this problem while cloning this repo a while ago, using a
slightly older version of git (probably 1.4.3, don't remember exactly).
In this repo, some directories appeared in the latest revisions which
were deleted a long time ago.

You can temporarily browse this repo here:
http://misc.j-crew.de/cgi-bin/gitweb.cgi?p=mediawiki.git
HEAD contains the dir Smarty-2.6.2, which was removed in SVN r3122.
Strangely, my repo misses all commits between r2991 and r3822.
You can see the gap at
http://misc.j-crew.de/cgi-bin/gitweb.cgi?p=mediawiki.git;a=shortlog;h=49e761ba51ee0d0a698999451134acbf2e078c03

I didn't notice any strange errors while cloning, but I had to abort and
restart git-svn a few times, so maybe there was some error there?

Anyway, I figured I didn't need the _whole_ history, so this is nothing
urgent, but I thought I should report it.

Re: Bug: git-svn fails on Mediawiki SVN repo r2992

[Eric Wong]

Thomas Bleher <bleher@informatik.uni-muenchen.de> wrote:
> There is some problem between git-svn (v1.4.4.1.gad0c3) and MediaWiki
> SVN when cloning their repo.
> 
> I just did
> $ git-svn init http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3
> $ git-svn fetch -r 2991:3122
> and git-svn went into an endless loop, repeatedly downloading and adding
> the same files from r2992 over and over again.

I'm not sure that it was 'endless', just unnecesarily repeating itself.
commit 6173c197c9a23fa8594f18fd2c856407d4af31c1 (included in 1.4.4.2)
should have fixed your problem...

> The bad revision can be viewed here:
> http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=2992
> It adds ~1000 files (mostly small images).
> I can check out this revision just fine using the svn command line
> client.

The latest git-svn in git.git now bundles all the changed files into a
delta on the server side; and is significantly faster over most network
connections as a result.

> I found this problem while cloning this repo a while ago, using a
> slightly older version of git (probably 1.4.3, don't remember exactly).
> In this repo, some directories appeared in the latest revisions which
> were deleted a long time ago.
> 
> You can temporarily browse this repo here:
> http://misc.j-crew.de/cgi-bin/gitweb.cgi?p=mediawiki.git
> HEAD contains the dir Smarty-2.6.2, which was removed in SVN r3122.
> Strangely, my repo misses all commits between r2991 and r3822.
> You can see the gap at
> http://misc.j-crew.de/cgi-bin/gitweb.cgi?p=mediawiki.git;a=shortlog;h=49e761ba51ee0d0a698999451134acbf2e078c03
> 
> I didn't notice any strange errors while cloning, but I had to abort and
> restart git-svn a few times, so maybe there was some error there?

Hmm, it looks like you ran something like:

	git-svn fetch -r0:2991

and then something along the lines of:

	git-svn fetch -r3822:HEAD

Is that what happened?

Looking at the pre-delta git-svn code, it seems that using -r with fetch
at any time other than the initial fetch will result in botched
history...

-- 

Re: Bug: git-svn fails on Mediawiki SVN repo r2992

[Thomas Bleher]

* Eric Wong <normalperson@yhbt.net> [2006-12-20 02:36]:
> Thomas Bleher <bleher@informatik.uni-muenchen.de> wrote:
> > There is some problem between git-svn (v1.4.4.1.gad0c3) and MediaWiki
> > SVN when cloning their repo.
> > 
> > I just did
> > $ git-svn init http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3
> > $ git-svn fetch -r 2991:3122
> > and git-svn went into an endless loop, repeatedly downloading and adding
> > the same files from r2992 over and over again.
> 
> I'm not sure that it was 'endless', just unnecesarily repeating itself.
> commit 6173c197c9a23fa8594f18fd2c856407d4af31c1 (included in 1.4.4.2)
> should have fixed your problem...

It fetched every file at least three times, and I had to kill it after
that, it had been running for over an hour already.
I just retried with current next, and it's _much_ faster, under one
minute now for this particular revision.

So consider this problem solved, and thanks a lot!

> > The bad revision can be viewed here:
> > http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=2992
> > It adds ~1000 files (mostly small images).
> > I can check out this revision just fine using the svn command line
> > client.
> 
> The latest git-svn in git.git now bundles all the changed files into a
> delta on the server side; and is significantly faster over most network
> connections as a result.

Yeah, this is a huge gain.

> > I found this problem while cloning this repo a while ago, using a
> > slightly older version of git (probably 1.4.3, don't remember exactly).
> > In this repo, some directories appeared in the latest revisions which
> > were deleted a long time ago.
> > 
> > You can temporarily browse this repo here:
> > http://misc.j-crew.de/cgi-bin/gitweb.cgi?p=mediawiki.git
> > HEAD contains the dir Smarty-2.6.2, which was removed in SVN r3122.
> > Strangely, my repo misses all commits between r2991 and r3822.
> > You can see the gap at
> > http://misc.j-crew.de/cgi-bin/gitweb.cgi?p=mediawiki.git;a=shortlog;h=49e761ba51ee0d0a698999451134acbf2e078c03
> > 
> > I didn't notice any strange errors while cloning, but I had to abort and
> > restart git-svn a few times, so maybe there was some error there?
> 
> Hmm, it looks like you ran something like:
> 
> 	git-svn fetch -r0:2991
> 
> and then something along the lines of:
> 
> 	git-svn fetch -r3822:HEAD
> 
> Is that what happened?

Nope. I just ran "git-svn fetch" repeatedly, and stopped it a few times
with ^C (the import was running for several days, and I had to turn off
the computer inbetween). Maybe something broke there?
Anyway, it's working now, so I think we can consider this problem
solved.

Thanks,
Thomas