Help debugging git-svn

Hello, Eric, Everybody!

I need your help getting git-svn to clone a repository.

I had already cloned it once but then a few months ago I discovered the authors map file and it's like the first time I did a checkout using git.... well, perhaps not that much, but close. Seeing the real names of people when using log, blame, etc is a major difference... so, back to my tale of sorts.

The thing is that I have already tried to clone it _several_ times and it always breaks at one point or another (or rather, at one revision of a branch or another). I have come to think that it's more or less at the same revisions that it breaks but I'm not 100% certain.

What I _think_ is the cause of most of the problems is that in our repo people have misplaced branches _inside_ other branches, at least for a few revisions before realizing their mistake and deleting it.

So.... say I have a standard layout.

trunk branches tags

Then at one point I copy trunk to branches/a

Later on I copy trunk to branches/b

Later on I copy trunk to branches/b/c (instead of branches/c)

And a few revisions later I realize my mistake and copy branches/b/c to branches/c and remove branches/b/c

I infer this because I'm seeing that on one of the revisions where git svn usually breaks when fetching has the content of the project inside a directory, like, say I have directories A, B and C in the project and I'm seeing that git svn is fetching a revision where the all the paths of the files are prepended by a directory that looks like a branch, like this:

branch_name/A/filea.txt branch_name/A/fileb.txt etc etc

Instead of A/filea.txt A/fileb.txt

So... throw some ideas around that... and then, could you tell a non-perl developer how to debug it? Perhaps increase verbosity?

One of the errors I see often when fetching (my memory tells me that it's associated to the branch-in-branch problem but I'm not completely sure right now), looks like this:

1 [main] perl 5652 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

And then, in the file:

Exception: STATUS_ACCESS_VIOLATION at rip=0048360C10C
rax=0000000601E4BFF8 rbx=000000005219E248 rcx=000000060003A590
rdx=0000000000000000 rsi=000000000000A950 rdi=0000000000000004
r8 =0000000000000000 r9 =0000000000000000 r10=0000000000230000
r11=000000048D78607A r12=0000000000000003 r13=000006FFFFF54A98
r14=0000000601E18030 r15=000006FFFFF54AB0
rbp=0000000000054A88 rsp=000000000022B810
program=C:\Program Files\Git\usr\bin\perl.exe, pid 5652, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

With my very flawed knowledge of perl I have seen that the process is getting to Ra.pm around here:

our $AUTOLOAD;
sub AUTOLOAD {
    my $class = ref($_[0]);
    $AUTOLOAD =~ s/^${class}::(SUPER::)?//;
    return if $AUTOLOAD =~ m/^[A-Z]/;

    my $self = shift;
    no strict 'refs';

    my $method = $self->can("invoke_$AUTOLOAD")
        or die "no such method $AUTOLOAD";

    no warnings 'uninitialized';
    $method->(@$self, @_);
}

The value of $AUTOLOAD there is 'finish_report' but I don't know (or at least see) where $method->(@$self, @_) is going.

Well... I think that's enough of a mess of a mail (sorry about that). Hope I was able to provide enough information to at least move a little bit forward.

Thanks in advance.

Edmundo Carmona Antoranz <eantoranz@gmail.com> wrote:

Any chance you can reproduce this on a Linux system? I do not use non-Free systems and have no debugging experience there at all.

It could also be a bug in the SVN bindings or the port of Perl. Which versions are you running?

I've also been wondering about the motivation of SVN developers to do a good job on maintaining their Perl bindings (given git-svn is likely the main user of them). We've certainly had problems in the past with SVN breaking and causing git-svn to segfault around 2011-2012; but it's been a while...

On Wed, Dec 16, 2015 at 1:41 AM, Eric Wong <normalperson@yhbt.net> wrote:

My wish.... But it's a big resounding "no".

I'm working on git for windows 2.6.3. I think I could use cygwin, just in case (I used it before).

Ok.... I came up with another idea to avoid having to deal with the old svn history (I'm having no problems fetching/dcommitting with my current repo). I already have the branches I work with, the thing is that the revisions I fetched before I started using the svn authors file have nasty IDs instead of human names. I though that I could create a script to rewrite the whole history of the project adjusting the usernames to real names (I'll take care of the details, no problem there... just found out about filter-branch, could work for what I'm thinking of). My question would be in the direction of rebuilding git-svn metainfo once I'm done so that I can continue fetching from svn as if nothing had happened. I checked the documentation in git-scm.com but didn't find the details about it. Is there a straight-forward document that explains how the git-svn metadata files are built?

Thanks in advance.

On Wed, Dec 16, 2015 at 6:36 AM, Edmundo Carmona Antoranz <eantoranz@gmail.com> wrote:

On Fri, Dec 18, 2015 at 11:28 AM, Edmundo Carmona Antoranz <eantoranz@gmail.com> wrote:

.rev_map files appear to be simple enough. I'll have fun with them a little bit. Will let you know how it goes later (don't hold your breath.... it might take a while).

Hi!

On Fri, Dec 18, 2015 at 10:31 PM, Edmundo Carmona Antoranz <eantoranz@gmail.com> wrote:

I was able to rewrite git-svn's history and I'm fetching/dcommitting as usual using the new branches. I posted the tool I developed for the task in github [1]. The readme explains how to use it.

Cheers!

[1] https://github.com/eantoranz/git_svn_rewrite