Re: minimize_url in git-svn?

[Eric Wong <normalperson@yhbt.net>]

Junio C Hamano <junkio@cox.net> 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