Possible bug in git-svn

Possible bug in git-svn

[Martin Eisenhardt]

[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]

Hello Eric,
hello list,

I came across what might just possibly be a bug in git-svn. My apologies if 
this was already handled somewhere on the list but I was not able to find 
this exact problem mentioned before.

Let's say I run a SVN repository at svn+ssh://svn@example.com/repos and have 
it set up as described at
	
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks

In essence, there is only one user "svn" with access to the repository, and 
every developer has his/her public key in ~svn/.ssh/authorized_keys with a 
line like

command="svnserve -t --tunnel-user=harry -r /svn/" TYPE1 KEY1 
harry@example.com

This is desirable to limit the developers access to the repository; no shell, 
access restricted to svn's home directory.

Now let's assume that within this repository, there are several projects, so 
we have f.e. the following structure:

+-proj1-+-trunk
|       +-branches
|       +-tags
|
+-proj2-+-trunk
|       +-branches
|       +-tags
+-[more projects]

I have no problem setting up a local .git tracking such a project using

    $ git-svn init svn+ssh://svn@example.com/repos/proj1/trunk
    $ git-svn fetch

After having made local changes and commited them to git, I want to push them 
to the remote subversion repository:

    $ # do some work
    $ git-commit -a
    $ git-svn dcommit

The last command gives me (invariably):

    Couldn't find a repository: No repository found 
in 'svn+ssh://example.com/repos/proj1/trunk' at at /home/mneisen/bin/git-svn 
line 403

What is odd is that git-svn uses the URL-prefix svn+ssh://example.com/[...] 
instead of the correct svn+ssh://svn@example.com/[...], i.e., git-svn drops 
the user name.

This behavior is surprisingly inconsistent as git-svn uses the correct user 
name while fetching and stores it correctly in .git/config.

The server log contains the following lines:

May 12 18:18:50 [sshd] Accepted keyboard-interactive/pam for mneisen from 
217.229.32.249 port 37685 ssh2
May 12 18:18:50 [sshd(pam_unix)] session opened for user mneisen by (uid=0)
May 12 18:18:51 [sshd(pam_unix)] session closed for user mneisen

which supports my suspicion that git-svn drops the user name for dcommit and 
uses the current account name instead.

A git repository on the same machine as the subversion repository is able to  
track the SVN repository, so it seems that my problems are directly related 
to the combination of git-svn and the svn+ssh transport of subversion.

If this an error on my part, please advise me how to solve it.

Kind regards
Martin Eisenhardt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Possible bug in git-svn

[Eric Wong]

Martin Eisenhardt <list-receive@mneisen.org> wrote:
> Hello Eric,
> hello list,
> 
> I came across what might just possibly be a bug in git-svn. My apologies if 
> this was already handled somewhere on the list but I was not able to find 
> this exact problem mentioned before.
> 
> Let's say I run a SVN repository at svn+ssh://svn@example.com/repos and have 
> it set up as described at
> 	
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
> 
> In essence, there is only one user "svn" with access to the repository, and 
> every developer has his/her public key in ~svn/.ssh/authorized_keys with a 
> line like
> 
> command="svnserve -t --tunnel-user=harry -r /svn/" TYPE1 KEY1 
> harry@example.com
> 
> This is desirable to limit the developers access to the repository; no shell, 
> access restricted to svn's home directory.
> 
> Now let's assume that within this repository, there are several projects, so 
> we have f.e. the following structure:
> 
> +-proj1-+-trunk
> |       +-branches
> |       +-tags
> |
> +-proj2-+-trunk
> |       +-branches
> |       +-tags
> +-[more projects]
> 
> I have no problem setting up a local .git tracking such a project using
> 
>     $ git-svn init svn+ssh://svn@example.com/repos/proj1/trunk
>     $ git-svn fetch
> 
> After having made local changes and commited them to git, I want to push them 
> to the remote subversion repository:
> 
>     $ # do some work
>     $ git-commit -a
>     $ git-svn dcommit
> 
> The last command gives me (invariably):
> 
>     Couldn't find a repository: No repository found 
> in 'svn+ssh://example.com/repos/proj1/trunk' at at /home/mneisen/bin/git-svn 
> line 403
> 
> What is odd is that git-svn uses the URL-prefix svn+ssh://example.com/[...] 
> instead of the correct svn+ssh://svn@example.com/[...], i.e., git-svn drops 
> the user name.
> 
> This behavior is surprisingly inconsistent as git-svn uses the correct user 
> name while fetching and stores it correctly in .git/config.

Ouch.  This is laziness on my part exposed by a patch Adam made to
cleanup the git-svn-id lines.  dcommit reads the git-svn-id: line in the
last SVN commit instead of .git/config.

> The server log contains the following lines:
> 
> May 12 18:18:50 [sshd] Accepted keyboard-interactive/pam for mneisen from 
> 217.229.32.249 port 37685 ssh2
> May 12 18:18:50 [sshd(pam_unix)] session opened for user mneisen by (uid=0)
> May 12 18:18:51 [sshd(pam_unix)] session closed for user mneisen
> 
> which supports my suspicion that git-svn drops the user name for dcommit and 
> uses the current account name instead.
> 
> A git repository on the same machine as the subversion repository is able to  
> track the SVN repository, so it seems that my problems are directly related 
> to the combination of git-svn and the svn+ssh transport of subversion.
> 
> If this an error on my part, please advise me how to solve it.

Thanks for the bug report.  I haven't tested the patch below, so
let me know if it works:

>From 58af622c222514dc3da938ce6309e1ac927a9574 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sat, 12 May 2007 14:36:20 -0700
Subject: [PATCH] git-svn: don't drop the username from URLs when dcommit is run

We no longer store usernames in URLs stored in git-svn-id lines
for dcommit, so we shouldn't rely on those URLs when connecting
to the remote repository to commit.
---
 git-svn.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index 3c4f490..d74e6d3 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -393,7 +393,7 @@ sub cmd_dcommit {
 		} else {
 			my %ed_opts = ( r => $last_rev,
 			                log => get_commit_entry($d)->{log},
-			                ra => Git::SVN::Ra->new($url),
+			                ra => Git::SVN::Ra->new($gs->full_url),
 			                tree_a => "$d~1",
 			                tree_b => $d,
 			                editor_cb => sub {
-- 
Eric Wong

[PATCH] git-svn: don't drop the username from URLs when dcommit is run

[Eric Wong]

Eric Wong <normalperson@yhbt.net> wrote:
> Martin Eisenhardt <list-receive@mneisen.org> wrote:
> 
> Thanks for the bug report.  I haven't tested the patch below, so
> let me know if it works:

Junio: I've confirmed this patch works, please apply.  Thanks.

>From 58af622c222514dc3da938ce6309e1ac927a9574 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sat, 12 May 2007 14:36:20 -0700
Subject: [PATCH] git-svn: don't drop the username from URLs when dcommit is run

We no longer store usernames in URLs stored in git-svn-id lines
for dcommit, so we shouldn't rely on those URLs when connecting
to the remote repository to commit.
---
 git-svn.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index 3c4f490..d74e6d3 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -393,7 +393,7 @@ sub cmd_dcommit {
 		} else {
 			my %ed_opts = ( r => $last_rev,
 			                log => get_commit_entry($d)->{log},
-			                ra => Git::SVN::Ra->new($url),
+			                ra => Git::SVN::Ra->new($gs->full_url),
 			                tree_a => "$d~1",
 			                tree_b => $d,
 			                editor_cb => sub {
-- 
Eric Wong

Re: Possible bug in git-svn

[Martin Eisenhardt]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

Hi Eric,
hi list,

On Saturday 12 May 2007 23:40:35 Eric Wong wrote:
> Thanks for the bug report.  I haven't tested the patch below, so
> let me know if it works:

Works like a charm for me, as others have already pointed out. Thanks you for 
the quick patch.

Kind regards
Martin Eisenhardt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]