3

I'm using git-svn to connect to a subversion repository that authenticates via https. I'm using the git command line client on Linux (Ubuntu 12.04). When I perform any command that requires interaction with the subversion server, I must enter my svn password, as expected. However, if the command requires multiple interactions with the svn server (e.g. git svn dcommit with multiple local commits) I must enter the password multiple times.

On another workstation, I have a similar setup which gives me the expect behavior of asking for the password once for the entire series of commits.

I've found similar questions here and here but in both cases the OP wanted the svn credentials cached between git-svn commands. I do not have subversion configured to cache my password and want to keep it that way if I can.

My git-svn version is 1.7.9.5 (svn 1.6.17)

Community
  • 1
  • 1
Beans Galore
  • 63
  • 1
  • 4

3 Answers3

1

The problem is that git svn commands perform multiple Subversion operations using a wrapper around the regular Subversion interfaces; Git doesn't know or care about your Subversion credentials.

I can see a few different options for proceeding, none of which are great:

  • Enable Subversion's credential store. You know about this and have said you don't want to do it, so that's a non-starter.

  • Just type the password in for every Subversion operation that Git performs. Your current solution; if that were good you wouldn't be asking the question.

  • Patch git svn. Git code is open source, and the git svn commands are written in Perl, so you can edit on your system and use the new version without recompiling. Rough design:

    • Whenever interacting with the Subversion repository, first attempt to perform it without interactive authentication (ie a --non-interactive argument to the underlying svn command).

    • If that works, great, carry on. If that fails, assume it fails due to lacking authentication, and prompt the user for a username and password.

    • For later svn commands, if no authentication was needed, carry on like that. Otherwise, specify the stored username and password explicitly (ie --username and --password arguments to the underlying svn command).

Going solo is far from trivial, though. Unless you particularly fancy some hard work digging around in the Git source code, or want this enough to pay someone to do that for you, it looks like this is behaviour you'll need to live with.

me_and
  • 15,158
  • 7
  • 59
  • 96
  • "Git doesn't know or care about your Subversion credentials." This points me in the direction of the subversion client itself temporarily caching my credentials. I wasn't sure if the git-svn wrapper was handling the svn credentials or whether that aspect was being passed to the svn client. I certainly don't want to pursue option 3 and I don't think I need to. My normal setup works just fine where I only need to enter the password once. It's perplexing to me why the setups are different and had I not seen expected behavior first, I likely would got with option 1 and be on my merry way. – Beans Galore Apr 03 '13 at 01:39
  • @BeansGalore: As far as I know, there's no way to have Subversion temporarily cache your credentials. As best I could tell from the Subversion docs, the caching is all-or-nothing and you can't tell it to discard the cache after a period of time. – me_and Apr 03 '13 at 13:29
  • That seems to be what I've found in the documentation as well. I'm wondering if gnome-keyring or some other similar process is caching something. I generally avoid any sort of credential caching on systems but something may be configured by default without my knowledge. – Beans Galore Apr 03 '13 at 17:19
  • I may have stumbled into a possible cause. On the configuration that 'works', I had mistakenly forgotten to do the '-s' on my git svn clone command. When I cloned to my other workstation, I used the '-s'. It's possible that the git-svn wrapper may do separate svn calls in the latter mode which could be the problem. I need to verify this. My resistance to credential caching may be futile. – Beans Galore Apr 03 '13 at 18:18
  • @Beans: that sounds entirely plausible to me. I don't have the time to dig in the source code to verify it, but fetching multiple folders from the Subversion repository (which is what `-s` will result in) sounds quite likely to cause separate Subversion operations for each folder. – me_and Apr 03 '13 at 23:02
0

You need to have the your credentials stored in the subversion directory. A naive solution would be to do a simple checkout of your svn repository in a temporary directory just to have svn saving your username and password:

svn co http://url-of-your-svn/repos/repos temp-repos-directory

In this way svn will ask if you want to save your credentials and they would be saved in your subversion config directory (~/.subversion/aut/ in linux).

Another solution would be ask directly svn to store your credentials:

svn update --username 'username' --password 'password'
Atropo
  • 12,231
  • 6
  • 49
  • 62
  • I appreciate the information. I would prefer not to have SVN cache my credentials in general. One of my setups functions exactly as I would expect. I only have to enter my password one time for a series of commands. I'm trying to understand how git-svn credential cache works but can't find a lot of documentation in general. I may have to fall back to your solution if I can't solve the problem. – Beans Galore Mar 29 '13 at 21:03
0

I tried hard to make svn (including git-svn) to save plain text password, but it turned out that actual version should be compiled with specific flag in order to do that. See this and this. My workaround was to use aliases like this:

echo $SVN_PASS | git svn fetch
Adam
  • 1,796
  • 18
  • 19