4

I'm trying to use git to clone an svn repository with std layout (using the -s option). The repository uses https anonymously (the repository is at https://secure.simplistix.com/svn/xlwt/). I can check the repository out fine using svn, but with git-svn I get password prompts and then cannot check out (I don't have an account for this repository):

Authentication realm:  Simplistix Subversion Server
Password for 'davidf': 
Authentication realm:  Simplistix Subversion Server
Username: 
Password for '': 
Authentication realm:  Simplistix Subversion Server
Username: 
Password for '': 
W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: '/svn/!svn/bc/100/xlwt' path not found
W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
This may take a while on large repositories

The resulting repository is entirely empty

git-svn seems to assume that if the repository starts with https, authentication is required. Is there a way to work around this?

David Fraser
  • 6,475
  • 1
  • 40
  • 56
  • I know this is old, but to help others please mention in your question and title that you’re using the `-s` option, since that is probably key to the issue you were seeing. – Daniel Cassidy Oct 03 '10 at 18:17
  • Good point. I've added that info. Anyone testing - I can't currently use `git svn` or `svn` on the above URL - I get a `OPTIONS` error with `200 OK` – David Fraser Oct 11 '10 at 15:22
  • As a followup to this, it's worth pointing out that xlwt development has now moved to github: https://github.com/python-excel/xlwt ...so, no need for gitsvn anymore! :-) – Chris Withers Oct 06 '12 at 23:38

2 Answers2

6

The reason is probably that the root of the SVN repository is not accessible to anonymous users.

From git help svn:

When tracking multiple directories (using --stdlayout, --branches, or --tags options), git svn will attempt to connect to the root (or highest allowed level) of the Subversion repository. This default allows better tracking of history if entire projects are moved within a repository, but may cause issues on repositories where read access restrictions are in place.

Since you’re using the -s option (shorthand for --stdlayout), this will affect you.

To prevent git svn from attempting to connect to the root of the repository, add the option --no-minimize-url to the command line.

See also: git help svn

Daniel Cassidy
  • 24,676
  • 5
  • 41
  • 54
  • so do you mean git svn will always fail if anonymous use cannot visit svn root? – hugemeow Aug 21 '12 at 23:26
  • @hugemeow it will fail if anonymous users cannot visit the root, **and** you use `--stdlayout`, or `--branches`, or `--tags`, or their equivalent short options, **and** you don’t specify `--no-minimize-url`. – Daniel Cassidy Aug 30 '12 at 20:42
2

I have an idea what this might be related to:

http://subversion.tigris.org/issues/show_bug.cgi?id=3242

If it's not that, then you're likely out of luck... The root of my repository is not publicly accessible...

Chris Withers
  • 10,837
  • 4
  • 33
  • 51
  • It does indeed look like that - git-svn clone can check the whole thing out, but add the -s to get branch support and it fails... however downgrading to subversion 1.4 doesn't fix it, so it seems that this is actually a similar bug in git-svn itself – David Fraser Mar 02 '10 at 07:21
  • hgsubversion rescues this as it doesn't access this in the same way, so that's a workaround... – David Fraser Mar 02 '10 at 07:59
  • Yeah, the problem is on the server, not on the client. – Chris Withers Jun 04 '10 at 06:33
  • @DavidFraser is hgsvn more powerful than git-svn? – hugemeow Aug 21 '12 at 23:24
  • @hugemeow - I haven't used hgsvn much (I think only when I was testing the above) so don't have much to comment on. I think these issues have been addressed in the svn server (see the issue linked above) although the above repository isn't there any more so I can't test exactly. – David Fraser Aug 22 '12 at 09:31