Re: git svn dcommit doesn't support --username option for file:/// urls

[Tim Ringenbach]

On Mon, Feb 15, 2016 at 3:14 PM, Eric Wong  wrote:
> It might take a while for me to get around to looking at this
> more, so it would be very helpful if you poked around and tried
> some different things in the source.

Ok, I played around with it some and found something that works.
I commented out all the providers except for:

   SVN::Client::get_username_prompt_provider(
 \::SVN::Prompt::username, 2)

And that seems to actually work!

Interestingly, it doesn't actually interactively prompt me for a
username. At least, not when I ran 'git svn dcommit --username test'.
It did when I later ran a 'git svn fetch'.

I don't know this API at all, and it's been a long time since I've
done any perl. (And I didn't even realize you used perl bindings to
libsvn until a few minutes ago, I just assumed you somehow implemented
everything from scratch.)

But my guess is that 'SVN::Client::get_username_provider()' is
provided by the perl binding and isn't git-svn specific, and so it
knows nothing of the --username argument, it simply is reading ~/.svn.
(Assuming git-svn reads ~/.svn at all.) (That hints at maybe I could
control the user with the files in ~/.svn, which I didn't even
consider previously.) And if it knows nothing about git-svn or any
arguments passed, then that explains why it didn't work.

Meanwhile, 'SVN::Client::get_username_prompt_provider' also looks like
a stock SVN::Client function, but it's passed in a Git::SVN::
argument, that I'm assuming is some sort of callback. So in that case
it's able to provided it with the passed in --username argument, or
failing that, it prompts me.

So I have something that I think will work for me. I'm not sure how to
turn it into a reasonable patch though. Maybe we need to eliminate
some of the auth_provides from the list if the --username option is
passed in?

> Btw, which version of SVN are you using?  I also wonder if
> there's something version-dependent.

svn --version
svn, version 1.6.12 (r955767)

I know that's pretty old.

Thanks,
Tim
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn dcommit doesn't support --username option for file:/// urls

[Eric Wong]

Tim Ringenbach  wrote:
> On Mon, Feb 15, 2016 at 4:06 AM, Eric Wong  wrote:
> [snip]
> > Totally untested, but does flipping the order of auth providers
> > help at all?
> 
> Thanks for looking into this. Unfortunately, that didn't seem to make
> a difference.

Thanks for trying.

It might take a while for me to get around to looking at this
more, so it would be very helpful if you poked around and tried
some different things in the source.

It should be helpful to look at any other SVN wrappers (or code
SVN itself).  In the past, I got a lot of help from looking at
svk/SVN::Mirror.

I'm certainly no expert when it comes to using the SVN API,
so it's likely we're doing something wrong...

Btw, which version of SVN are you using?  I also wonder if
there's something version-dependent.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn dcommit doesn't support --username option for file:/// urls

[Tim Ringenbach]

On Mon, Feb 15, 2016 at 4:06 AM, Eric Wong  wrote:
[snip]
> Totally untested, but does flipping the order of auth providers
> help at all?

Thanks for looking into this. Unfortunately, that didn't seem to make
a difference.
I tried several times, and I tried both with and without
--interactive, but the commits
always shared up as my unix user.

I added a "print "test\n";" to make sure my modify copy was being
used, and I did see
that output, so I know I was running the right code.

For reference, here's what diff outputs on my side.

--- git-2.7.1/perl/Git/SVN/Ra.pm 2016-02-05 17:31:08.0 -0600
+++ local/share/perl/5.10.1/Git/SVN/Ra.pm 2016-02-15 13:06:27.0 -0600
@@ -42,7 +42,9 @@ END {

 sub _auth_providers () {
  require SVN::Client;
+ print "test\n";
  my @rv = (
+  SVN::Client::get_username_provider(),
   SVN::Client::get_simple_provider(),
   SVN::Client::get_ssl_server_trust_file_provider(),
   SVN::Client::get_simple_prompt_provider(
@@ -53,7 +55,6 @@ sub _auth_providers () {
   SVN::Client::get_ssl_client_cert_pw_file_provider(),
   SVN::Client::get_ssl_client_cert_pw_prompt_provider(
 \::SVN::Prompt::ssl_client_cert_pw, 2),
-  SVN::Client::get_username_provider(),
   SVN::Client::get_ssl_server_trust_prompt_provider(
 \::SVN::Prompt::ssl_server_trust),
   SVN::Client::get_username_prompt_provider(


Thanks,
Tim
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn dcommit doesn't support --username option for file:/// urls

[Eric Wong]

Tim Ringenbach  wrote:
> Hi,
> 
> 'git svn dcommit' doesn't seem to honor the --username argument when
> my svn repository url is a file:/// url.  It doesn't complain either,
> it just seems to silently ignore the option. My dcommits show up as
> the user I'm logged in as. The only way I found to change that is to
> 'sudo' to some other user.
> 
> The actual 'svn' command does support --username with 'svn commit'.

Interesting, I didn't know --username would be handled with
file:// at all by svn(1).  I don't think we do anything special
depending on the URL scheme for auth, either.

I took a quick look at the svn(1) code
(subversion/svn/svn.c in git://git.apache.org/subversion.git)
but didn't see anything jump out at me (I'm not really familiar
with that code, either).

Totally untested, but does flipping the order of auth providers
help at all?

diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index e764696..c6ce247 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -43,6 +43,7 @@ END {
 sub _auth_providers () {
require SVN::Client;
my @rv = (
+ SVN::Client::get_username_provider(),
  SVN::Client::get_simple_provider(),
  SVN::Client::get_ssl_server_trust_file_provider(),
  SVN::Client::get_simple_prompt_provider(
@@ -53,7 +54,6 @@ sub _auth_providers () {
  SVN::Client::get_ssl_client_cert_pw_file_provider(),
  SVN::Client::get_ssl_client_cert_pw_prompt_provider(
\::SVN::Prompt::ssl_client_cert_pw, 2),
- SVN::Client::get_username_provider(),
  SVN::Client::get_ssl_server_trust_prompt_provider(
\::SVN::Prompt::ssl_server_trust),
  SVN::Client::get_username_prompt_provider(


(I'm not sure if it breaks other things, either).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git svn dcommit doesn't support --username option for file:/// urls

[Tim Ringenbach]

Hi,

'git svn dcommit' doesn't seem to honor the --username argument when
my svn repository url is a file:/// url.  It doesn't complain either,
it just seems to silently ignore the option. My dcommits show up as
the user I'm logged in as. The only way I found to change that is to
'sudo' to some other user.

The actual 'svn' command does support --username with 'svn commit'.

What I'm actually up to, is trying to make a svn to git mirror
bi-directional. Right now, I have a cron job that 'git svn fetch's and
'git push origin's with some configs setup so that it does what I
want.

I was experimenting with writing some scripting to go in the other
direction, and my first step was seeing if I could commit to svn as
any user.  It seems like I should be able to and that git-svn just
doesn't support it.

(BTW, I'm aware there's a lot of pitfalls I'll have to work around,
and that I'll need to be very careful with verifying that the most
recent 'git-svn-id:' matches the branch and revision I expect to be
committing to, and that bad things will happen if I mess it up.)

Thanks,
Tim
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html