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

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

[esskov]

	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

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

[Eric Wong]

esskov@oncable.dk wrote:
> 	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?

> 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?

-- 
Eric Wong

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

[Esben Skovenborg]

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

On Thu, 9 Jul 2009 20:31:33 -0700, Eric Wong wrote:
>esskov@oncable.dk wrote:
>> 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/trunk@1-10 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

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

>> 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 :)

>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?

>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

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

[Eric Wong]

Esben Skovenborg <esskov@oncable.dk> wrote:
> On Thu, 9 Jul 2009 20:31:33 -0700, Eric Wong wrote:
> >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...

> >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

[PATCH] git svn: allow uppercase UUIDs from SVN

[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 <normalperson@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;
-- 
Eric Wong

Re: [PATCH] git svn: allow uppercase UUIDs from SVN

[Junio C Hamano]

Eric Wong <normalperson@yhbt.net> writes:

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

Thanks, will pull.

Re: [PATCH] git svn: allow uppercase UUIDs from SVN

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Eric Wong <normalperson@yhbt.net> writes:
>
>>   Junio: pushed out to git://git.bogomips.org/git-svn along with
>>          some patches I think I forgot to tell you about:
>
> 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 <ydirson@altern.org>
    Date:   Mon Jul 6 00:03:15 2009 +0200

which is an old iteration of 

    commit 6c32a7a99495da3f49e2a142791bc10af3f6f059
    Author: Yann Dirson <ydirson@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.

Re: [PATCH] git svn: allow uppercase UUIDs from SVN

[Eric Wong]

Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Eric Wong <normalperson@yhbt.net> writes:
> >
> >>   Junio: pushed out to git://git.bogomips.org/git-svn along with
> >>          some patches I think I forgot to tell you about:
> >
> > 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 <ydirson@altern.org>
>     Date:   Mon Jul 6 00:03:15 2009 +0200
> 
> which is an old iteration of 
> 
>     commit 6c32a7a99495da3f49e2a142791bc10af3f6f059
>     Author: Yann Dirson <ydirson@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:

Exactly, just pushed.  Sorry about that.

-- 
Eric Wong