git-svn sucks when it should not

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Eric,

I have the pleasure of needing to work with a subversion project where 
parts of the webserver are password restricted.

In particular, I cannot access the parent directory, and one of 
the branches is protected, too.

Maybe you remember me describing that problem on IRC a few weeks ago: yes, 
it is still persistent.

Now, I thought that I know my way around Perl, at least a little bit, but 
while git-svn barfed on the repository, I... uhm, well, you probably get 
the idea.

The funny part is this: when I say "git svn clone $URL/trunk", or the same 
with the absolute paths to the single tags, instead of "git svn clone -s 
$URL", git-svn does the correct thing.  It works, importing the stuff as 
"git-svn".

So I tried to just edit out by hand the branches section, so that the 
password-protected branch would not be a problem.

The result was surprising: git svn fetch exited with success, but it 
did... absolutely nothing.

After a lot of frustrating hours, which were not at all helped by 
brilliant variable names such as "r" and "gsv", I now know this: the log 
contains paths that do not have a prefix "trunk", but "<dir>/trunk", 
where "<dir>" is the last directory of the URL.

Changing git-svn's URL to the parent of <dir> is a no-go, since that is -- 
as I mentioned above -- password protected.

Yes, in a perfect world I could just force the admin to change that, but 
no, this is not a perfect world, so do not even try to suggest that if 
you want to help.

Changing the fetch line to "<dir>/trunk:refs/remotes/trunk" does not work 
either, since git-svn cleverly checks $URL/<dir>/<dir>/trunk/.

I then tried to hack match_globs() and match_paths() to add that extra 
prefix to the patterns, so that that extra prefix + trunk would be 
matched and edited out.  This happened to work out alright.

But I tried for several hours to get in a proper solution which does not 
throw up on the tags, and I have to conclude that this piece of code is 
not hackable by anybody else but you.

So I stand defeated by your program.  Thank you.

My ugly, ugly workaround that is however easy, easy, is a shell script 
that uses curl to find out what refs are new, and clones each ref 
individually, then pushes all the results together into one repository.

Should not have been _that_ hard,
Dscho

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux