Re: git-svn goes into infinite loop rebuilding rev_map

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

 



On Fri, May 16, 2008 at 2:02 PM, Daniel Berlin <dberlin@xxxxxxxxxxx> wrote:
> On Fri, May 16, 2008 at 1:48 PM, Kevin Ballard <kevin@xxxxxx> wrote:
>> On May 16, 2008, at 1:15 PM, Daniel Berlin wrote:
>>
>>> Starting last night, for no particularly obvious reason, git-svn fetch
>>> (or git-svn rebase or any command that does naything interesting) on
>>> gcc.gnu.org's repo causes git-svn to do the following:
>>>

I finally got a chance to debug this a bit, and it appears to occur
because rewriteRoot is not taken into account during rebuilding of
metadata.


In this loop in rebuild:
 while (<$log>) {
                if ( m{^commit ($::sha1)$} ) {
                        $c = $1;
                        next;
                }
                next unless s{^\s*(git-svn-id:)}{$1};
                my ($url, $rev, $uuid) = ::extract_metadata($_);
                remove_username($url);

                # ignore merges (from set-tree)
                next if (!defined $rev || !$uuid);
                print "uuid:$uuid, svn_uuid:$svn_uuid, full_url:
$full_url, url: $url!\n";
                my $rwr = $self->rewrite_root;

                # if we merged or otherwise started elsewhere, this is
                # how we break out of it

                if (($uuid ne $svn_uuid) ||
                    ($full_url && $url && ($url ne $full_url))) {
                        next;
                }

                $self->rev_map_set($rev, $c);
                print "r$rev = $c\n";
        }

We end up with
uuid:138bc75d-0d04-0410-961f-82ee72b054a4,
svn_uuid:138bc75d-0d04-0410-961f-82ee72b054a4, full_url:
file:///svn/gcc/trunk, url: svn+ssh://gcc.gnu.org/svn/gcc/trunk

This is because we fetch from the local fs but rewriteRoot it into a
path that works for remote users who want to commit.

However, in that loop that $full_url ne $url so it skips setting the
rev in the rev map, under the assumption it came from elsewhere.

Since it does this for every rev, it never actually puts anything in
the rev map (which means it never creates it).
So it decides to rebuild it again since the file existence fails.
Lather, Rinse, Repeat

The correct fix (i'm not good enough at perl/git-svn to know how to
write this code) is to take rewriteRoot into account.
In addition, it might make sense to assert that when we rebuild the
rev_map, it actually exists when we are done :).

HTH,
Dan
--
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