git-svn is "Unable to determine upstream SVN information..."

[e***@oncable.dk]

Hi,

I'm trying to clone the trunk of an svn repo, so that I can work on a set
of patches locally, and then occasionally push some of them back to svn.

The git-svn clone seems to go well, and the resulting git log looks
alright. However, git-svn info and git-svn rebase both say "Unable to
determine upstream SVN information from working tree history".
Also, git-svn log shows nothing. I'm using the svn:// protocol btw, but I
guess the protocol shouldn't matter?

To test if this was a general problem, I just tried to git-svn clone a
repo on some public svn server which was also using the svn protocol. I
used exactly the same syntax for the svn init and fetch commands. However,
the resulting git repo did NOT suffer from the problem, i.e., git-svn info
reported nicely etc.

At some point I suspected that there might be a problem with the
"git-svn-id ..." lines in the commits for the problematic repo, but they
look just like the ones for the working repo. The .git/config files of the
working and the non-working git-repos are similar as well.

What could be causing this problem?


Cheers,

Esben

[Eric Wong]

Post by e***@oncable.dk
Hi,
I'm trying to clone the trunk of an svn repo, so that I can work on a set
of patches locally, and then occasionally push some of them back to svn.
The git-svn clone seems to go well, and the resulting git log looks
alright. However, git-svn info and git-svn rebase both say "Unable to
determine upstream SVN information from working tree history".
Also, git-svn log shows nothing. I'm using the svn:// protocol btw, but I
guess the protocol shouldn't matter?

Protocol shouldn't matter. Do you have any non-linear history from
merges in git? git-svn (and SVN) doesn't play very nicely with
non-linear history that git merges can generate.

Does having a clean clone of that repo fix things? You didn't use
--no-metadata or blow away your .git/svn/* directories, did you?

Post by e***@oncable.dk
To test if this was a general problem, I just tried to git-svn clone a
repo on some public svn server which was also using the svn protocol. I
used exactly the same syntax for the svn init and fetch commands. However,
the resulting git repo did NOT suffer from the problem, i.e., git-svn info
reported nicely etc.
At some point I suspected that there might be a problem with the
"git-svn-id ..." lines in the commits for the problematic repo, but they
look just like the ones for the working repo. The .git/config files of the
working and the non-working git-repos are similar as well.
What could be causing this problem?

Which version of git svn is this? Are there any weird characters in the
URL? Off the top of my head I can't think of anything else; I assume
you're not allowed to share access to the repo (or to the clone) you're
having problems with?

[Esben Skovenborg]

Thanks for your quick reply! Let me go through your check-list...

Post by Eric Wong

Post by e***@oncable.dk
I'm trying to clone the trunk of an svn repo, so that I can work on a set
of patches locally, and then occasionally push some of them back to svn.
The git-svn clone seems to go well, and the resulting git log looks
alright. However, git-svn info and git-svn rebase both say "Unable to
determine upstream SVN information from working tree history".
Also, git-svn log shows nothing. I'm using the svn:// protocol btw, but I
guess the protocol shouldn't matter?

Protocol shouldn't matter. Do you have any non-linear history from
merges in git? git-svn (and SVN) doesn't play very nicely with
non-linear history that git merges can generate.
Does having a clean clone of that repo fix things? You didn't use
--no-metadata or blow away your .git/svn/* directories, did you?

I do get the problem with a clean clone, and I don't see any difference
between the structure of the .git/svn/* of the problematic repo and of the
working test-repo.

The problem can be reproduced as simple as this:
$ git svn init svn://svn.xxx.xxx/xxx/trunk
$ git svn fetch -r BASE:10
$ git branch -a
* master
remotes/git-svn
$ git svn info
Unable to determine upstream SVN information from working tree
history
$ git log
each commit shows line like: "a git-svn-id:
svn://svn.xxx.xxx/xxx/***@1-10 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

These 10 revisions only consist of file insertions and deletions in the
trunk.

Post by Eric Wong

Post by e***@oncable.dk
To test if this was a general problem, I just tried to git-svn clone a
repo on some public svn server which was also using the svn protocol. I
used exactly the same syntax for the svn init and fetch commands. However,
the resulting git repo did NOT suffer from the problem, i.e., git-svn info
reported nicely etc.
At some point I suspected that there might be a problem with the
"git-svn-id ..." lines in the commits for the problematic repo, but they
look just like the ones for the working repo. The .git/config files of the
working and the non-working git-repos are similar as well.
What could be causing this problem?

Which version of git svn is this?

I see the problem with both git version 1.6.3.2.1299.gee46c (msysgit) and
git version 1.6.3.3.412.gf581d (Ubuntu). The latter contains your fix for
that other problem I encountered :)

Post by Eric Wong
Are there any weird characters in the URL?

No. The only thing 'different' about this svn server is that it uses
authentication (i.e. asks for name+password). But I suppose that when the
git-svn fetch goes well, then this is not the problem? Do the git-svn
info and git-svn rebase even need to access the svn server?

Post by Eric Wong
Off the top of my head I can't think of anything else; I assume
you're not allowed to share access to the repo (or to the clone) you're
having problems with?

Right, at least it's something we should talk about off-list.

Is there any way of asking git-svn *why* it is "unable to determine
upstream SVN information from working tree history" ?


Cheers,

Esben

[Eric Wong]

Post by Esben Skovenborg

Post by Eric Wong
Are there any weird characters in the URL?

No. The only thing 'different' about this svn server is that it uses
authentication (i.e. asks for name+password). But I suppose that when the
git-svn fetch goes well, then this is not the problem? Do the git-svn
info and git-svn rebase even need to access the svn server?

Yes, rebase (without the -l) option needs it for sure. I think info can
optionally use it, too. Does enabling authentication caching (enabled
by default in SVN) help things? I haven't used the authentication
prompt pieces in ages, they're hard to test in an automated fashion so
they may have bit-rotted since I last looked at them...

Post by Esben Skovenborg

Post by Eric Wong
Off the top of my head I can't think of anything else; I assume
you're not allowed to share access to the repo (or to the clone) you're
having problems with?

Right, at least it's something we should talk about off-list.
Is there any way of asking git-svn *why* it is "unable to determine
upstream SVN information from working tree history" ?

If you're comfortable with a little Perl, you can sprinkle some debug
statements in working_head_info(). Feel free to email me directly
offlist but my schedule looks pretty hectic today and this weekend
and I may be offline a lot.

[Eric Wong]

SVN allows uppercase A-F characters in repositories. Although
`svnadmin' does not create UUIDs with uppercase by default, it
is possible to change the UUID of a SVN repository and SVN
itself will make no attempt to normalize them.

Thanks to Esben Skovenborg for discovering this issue.

Signed-off-by: Eric Wong <***@yhbt.net>
---

Esben: thank you for helping me find and confirming the fix!

Junio: pushed out to git://git.bogomips.org/git-svn along with
some patches I think I forgot to tell you about:

Eric Wong (1):
git svn: allow uppercase UUIDs from SVN

Mattias Nissler (2):
git-svn: Always duplicate paths returned from get_log
git-svn: Fix branch detection when repository root is inaccessible

git-svn.perl | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index ec84758..cfade63 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1359,11 +1359,11 @@ sub read_repo_config {
sub extract_metadata {
my $id = shift or return (undef, undef, undef);
my ($url, $rev, $uuid) = ($id =~ /^\s*git-svn-id:\s+(.*)\@(\d+)
- \s([a-f\d\-]+)$/x);
+ \s([a-f\d\-]+)$/ix);
if (!defined $rev || !$uuid || !$url) {
# some of the original repositories I made had
# identifiers like this:
- ($rev, $uuid) = ($id =~/^\s*git-svn-id:\s(\d+)\@([a-f\d\-]+)/);
+ ($rev, $uuid) = ($id =~/^\s*git-svn-id:\s(\d+)\@([a-f\d\-]+)/i);
}
return ($url, $rev, $uuid);
}
@@ -2010,7 +2010,7 @@ sub _set_svm_vars {

chomp($src, $uuid);

- $uuid =~ m{^[0-9a-f\-]{30,}$}
+ $uuid =~ m{^[0-9a-f\-]{30,}$}i
or die "doesn't look right - svm:uuid is '$uuid'\n";

# the '!' is used to mark the repos_root!/relative/path
@@ -2096,7 +2096,7 @@ sub svnsync {
die "doesn't look right - svn:sync-from-url is '$url'\n";

my $uuid = tmp_config('--get', "$section.svnsync-uuid");
- ($uuid) = ($uuid =~ m{^([0-9a-f\-]{30,})$}) or
+ ($uuid) = ($uuid =~ m{^([0-9a-f\-]{30,})$}i) or
die "doesn't look right - svn:sync-from-uuid is '$uuid'\n";

$svnsync = { url => $url, uuid => $uuid }
@@ -2114,7 +2114,7 @@ sub svnsync {
die "doesn't look right - svn:sync-from-url is '$url'\n";

my $uuid = $rp->{'svn:sync-from-uuid'} or die $err . "uuid\n";
- ($uuid) = ($uuid =~ m{^([0-9a-f\-]{30,})$}) or
+ ($uuid) = ($uuid =~ m{^([0-9a-f\-]{30,})$}i) or
die "doesn't look right - svn:sync-from-uuid is '$uuid'\n";

my $section = "svn-remote.$self->{repo_id}";
@@ -2130,7 +2130,7 @@ sub ra_uuid {
unless ($self->{ra_uuid}) {
my $key = "svn-remote.$self->{repo_id}.uuid";
my $uuid = eval { tmp_config('--get', $key) };
- if (!$@ && $uuid && $uuid =~ /^([a-f\d\-]{30,})$/) {
+ if (!$@ && $uuid && $uuid =~ /^([a-f\d\-]{30,})$/i) {
$self->{ra_uuid} = $uuid;
} else {
die "ra_uuid called without URL\n" unless $self->{url};
@@ -2848,7 +2848,7 @@ sub make_log_entry {
die "Can't have both 'useSvmProps' and 'rewriteRoot' ",
"options set!\n";
}
- my ($uuid, $r) = $headrev =~ m{^([a-f\d\-]{30,}):(\d+)$};
+ my ($uuid, $r) = $headrev =~ m{^([a-f\d\-]{30,}):(\d+)$}i;
# we don't want "SVM: initializing mirror for junk" ...
return undef if $r == 0;
my $svm = $self->svm;

[Junio C Hamano]

Post by Eric Wong
Junio: pushed out to git://git.bogomips.org/git-svn along with

Thanks, will pull.

[Junio C Hamano]

Post by Junio C Hamano

Post by Eric Wong
Junio: pushed out to git://git.bogomips.org/git-svn along with

Thanks, will pull.

Actually I think I got something different from what I thought I was
expecting. Your message said:

Eric Wong (1):
git svn: allow uppercase UUIDs from SVN

Mattias Nissler (2):
git-svn: Always duplicate paths returned from get_log
git-svn: Fix branch detection when repository root is inaccessible

but after merge:

Junio C Hamano (1):
Merge git://git.bogomips.org/git-svn

Mattias Nissler (2):
git-svn: Always duplicate paths returned from get_log
git-svn: Fix branch detection when repository root is inaccessible

Yann Dirson (4):
git-svn.txt: stop using dash-form of commands.
git-svn.txt: make formatting more consistent.
git-svn.txt: fix fetch flags incorrectly documented as init flags.
git-svn.txt: fix description of fetch flags accepted by clone.

For example, you have this:

commit eb0d671e3b73f05106dca83b9cecd74d4acdb291
Author: Yann Dirson <***@altern.org>
Date: Mon Jul 6 00:03:15 2009 +0200

which is an old iteration of

commit 6c32a7a99495da3f49e2a142791bc10af3f6f059
Author: Yann Dirson <***@altern.org>
Date: Tue Jul 7 22:22:20 2009 +0200

that is already in 'master'.

Perhaps you forgot to push it out? These are what I see:

$ git fetch git://git.bogomips.org/git-svn HEAD
$ git log --oneline ..FETCH_HEAD
6bb8ed9 git-svn: Fix branch detection when repository root is inaccessible
2d4b387 git-svn: Always duplicate paths returned from get_log
bca5572 git-svn.txt: fix description of fetch flags accepted by clone.
e594175 git-svn.txt: fix fetch flags incorrectly documented as init flags.
eb0d671 git-svn.txt: make formatting more consistent.
6478d74 git-svn.txt: stop using dash-form of commands.

[Eric Wong]

Post by Junio C Hamano

Post by Junio C Hamano

Post by Eric Wong
Junio: pushed out to git://git.bogomips.org/git-svn along with

Thanks, will pull.

Actually I think I got something different from what I thought I was
git svn: allow uppercase UUIDs from SVN
git-svn: Always duplicate paths returned from get_log
git-svn: Fix branch detection when repository root is inaccessible
Merge git://git.bogomips.org/git-svn
git-svn: Always duplicate paths returned from get_log
git-svn: Fix branch detection when repository root is inaccessible
git-svn.txt: stop using dash-form of commands.
git-svn.txt: make formatting more consistent.
git-svn.txt: fix fetch flags incorrectly documented as init flags.
git-svn.txt: fix description of fetch flags accepted by clone.
commit eb0d671e3b73f05106dca83b9cecd74d4acdb291
Date: Mon Jul 6 00:03:15 2009 +0200
which is an old iteration of
commit 6c32a7a99495da3f49e2a142791bc10af3f6f059
Date: Tue Jul 7 22:22:20 2009 +0200
that is already in 'master'.

Exactly, just pushed. Sorry about that.