From: "Daniel Berlin" <dberlin@dberlin.org>
To: "Kevin Ballard" <kevin@sb.org>
Cc: "Git Mailing List" <git@vger.kernel.org>, normalperson@yhbt.net
Subject: Re: git-svn goes into infinite loop rebuilding rev_map
Date: Sun, 18 May 2008 23:30:55 -0400 [thread overview]
Message-ID: <4aca3dc20805182030v4ff6707bo997dfb34110305d4@mail.gmail.com> (raw)
In-Reply-To: <4aca3dc20805161102y2de0d95cif8a6b643abf722e8@mail.gmail.com>
On Fri, May 16, 2008 at 2:02 PM, Daniel Berlin <dberlin@dberlin.org> wrote:
> On Fri, May 16, 2008 at 1:48 PM, Kevin Ballard <kevin@sb.org> 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
prev parent reply other threads:[~2008-05-19 3:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-16 17:15 git-svn goes into infinite loop rebuilding rev_map Daniel Berlin
2008-05-16 17:48 ` Kevin Ballard
2008-05-16 18:02 ` Daniel Berlin
2008-05-19 3:30 ` Daniel Berlin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4aca3dc20805182030v4ff6707bo997dfb34110305d4@mail.gmail.com \
--to=dberlin@dberlin.org \
--cc=git@vger.kernel.org \
--cc=kevin@sb.org \
--cc=normalperson@yhbt.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).