Re: git-svn fails to fetch repository

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jay Soffian <jaysoffian@xxxxxxxxx> wrote:
> On Wed, Jan 14, 2009 at 3:32 AM, Vladimir Pouzanov <farcaller@xxxxxxxxx> wrote:
> > Jay Soffian <jaysoffian <at> gmail.com> writes:
> >> So you're adding the "use Carp..." and "warn..." lines.
> >>
> >> Then try the import again. That should at least show why the svn_delta
> >> temp file is being acquired twice.
> >
> > Output is pretty long so I've put in on pastebin:
> > http://pastebin.com/m210be905
> 
> Okay, this is beyond me. git-svn (among other things) implements a
> so-called delta editor (part of the subversion API). The driver for
> that editor is apparently calling the editor's apply_textdelta()
> method twice in a row w/o an intervening call to the editor's
> close_file() method.
> 
> I don't understand when and/or why it would do this. This part of the
> Subversion API seems not that well documented, and I got lost trying
> to follow all the indirections in the Subversion source code (esp
> w/the swig'ified Perl bindings). AFAICT, this should not be happening.

Thank you Jay for your help and patch so far.  I'm sorry you had to go
through the craziness that is the Subversion library (and associated
craziness that leaked into git-svn) to try an debug this problem.

> I could ask you to insert some more debugging statements to try to
> track it to a specific file (or files), but I think at this point I'll
> going to wait to see if the git-svn author has any ideas.

Putting "print" and "print Dumper(\@_)" everywhere is pretty much
how I figured out how to use the delta interface the first time around.

Vladimir:

I can't reproduce this problem at all, either.  git-svn dups the file
handle in question, maybe your combination of (SVN/Perl/OSX) somehow
handles dup'd file descriptors differently?

Does the following patch (a shot in the dark) work for you?
(it generates a lot of warnings for me)

diff --git a/git-svn.perl b/git-svn.perl
index ad01e18..23e6925 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3361,6 +3361,7 @@ sub apply_textdelta {
 	seek $base, 0, 0 or croak $!;
 	$fb->{fh} = $fh;
 	$fb->{base} = $base;
+	$fb->{dup} = $dup;
 	[ SVN::TxDelta::apply($base, $dup, undef, $fb->{path}, $fb->{pool}) ];
 }
 
@@ -3408,6 +3409,7 @@ sub close_file {
 
 		Git::temp_release($fb->{base}, 1);
 		Git::temp_release($fh, 1);
+		eval { Git::temp_release($fb->{dup}, 1) };
 	} else {
 		$hash = $fb->{blob} or die "no blob information\n";
 	}

> BTW, it doesn't help any that the order that files are checked out
> seems not to be consistent. Not only is my git-svn clone working, the
> order my files are checked out in is different from yours.
> 
> Oh, one other thing I don't understand is why the debugging output is
> now showing that some files are being added for you (the lines
> beginning with \tA). Before you weren't getting that. I had thought
> these lines might be getting lost in stdout buffering, but git-svn
> disables buffering on stdout, so color me confused.

With that comment and my attempted fix above, I'm almost under the
impression that something on Vladimir's system (or Perl) is
configured to handle I/O in some weird/broken way...

-- 
Eric Wong
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux