Junio C Hamano <junkio@xxxxxxx> wrote: > I was trying to run git-svn against this: > > https://repo.socialtext.net:8999/svn/socialtext/trunk > > This is an open source project [*1*] and the trunk is supposed > to be readable by everybody, but it seems that anything outside > that area needs authentication. If I mimick the example in > git-svn.txt manual page to clone from there, it creates trunk, > trunk/.git, and then asks for password: > > $ URL=https://repo.socialtext.net:8999/svn/socialtext/trunk > $ git-svn clone $URL > Authentication realm: <https://repo.socialtext.net:8999> Auth for SVN > Password for 'junio': ^C > > I've narrowed it down to this part of git-svn. If I tell it not > to bother "minimiz"ing the URL, it seems to import without > stepping outside of the URL it was given. > > --- a/git-svn.perl > +++ b/git-svn.perl > @@ -1038,7 +1038,8 @@ > } > $self->{repo_id} = $existing; > } else { > - my $min_url = Git::SVN::Ra->new($url)->minimize_url; > + my $ra = Git::SVN::Ra->new($url); > + my $min_url = $url; # $ra->minimize_url; > $existing = find_existing_remote($min_url, $r); > if ($existing) { > unless ($no_write) { That should be fine. > Two and half questions. > > * What does minimize do, and why is it necessary? I try to connect to the root (or closer to the root) of the repository. This allows branches and tags to be tracked more effectively without needing reconnects. There's a reparent function in SVN 1.4, but it doesn't work correctly with svn:// repos last I checked (1.4.3) > * The resulting git-svn remote tracking branch (and 'master') > seems to check out fine, but I do not know what damage the > hack to avoid minimizing is causing. Are there any? I see > many 0{40} lines in trunk/.git/svn/git-svn/.rev_db.* file, > and also many lines in unhandled.log file (+empty_dir, > +file_prop, and +dir_prop). Are these something to worry > about? Nope. unhandled.log is strictly informational. .rev_db is offset-based database. Revision numbers to git commits can be looked up using (SVN revision * 41). If the project has really high revision numbers (like gcc) or lots of tags, it's a space-killer. I've been meaning to add an optional SQLite alternative to .rev_db for people tracking those projects. Patches welcome :) > * Assuming there aren't any damage, or maybe some damage that > would cause minor decreased functionality/interoperability, > would it perhaps make sense to optionally allow skipping the > minimizing to avoid this problem? Would it make sense, or is > the setting at socialtext site too esoteric and it isn't > worth to worry about? It *should* be automatically detecting the highest level up it can access and stop there. In your case, there's obviously something broken in my code :( I've definitely tested this as working against Seth Falcon's hedgehog repo (URL is somewhere in the archives). I also setup a test repository somewhere that I can double-check against. > [Footnote] > > *1* http://www.socialtext.net/stoss/index.cgi?developing_with_a_dev_env I'll try to take a look at that in the next few days. I also have segfaults to fix that I haven't gotten to :( -- Eric Wong - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
