Re: [RFC PATCH] git-svn does not support intermediate directories?

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

 



I did some additional hacking and may have found a slightly cleaner
way of at least fixing the problems with "git svn fetch".  The problem
with the wrong paths being initialized for branches and tags is fairly
minor (since you can just edit the config by hand), so I'll probably
address that later, if I have time.  Here's the patch (I hope I'm
doing this right):

diff --git a/git-svn.perl b/git-svn.perl
index 959eb52..174f266 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2351,7 +2351,11 @@ sub match_paths {
        if (my $path = $paths->{"/$self->{path}"}) {
                return ($path->{action} eq 'D') ? 0 : 1;
        }
-       $self->{path_regex} ||= qr/^\/\Q$self->{path}\E\//;
+       my $repos_root = $self->ra->{repos_root};
+       my $intermediate_path = $self->{url};
+       $intermediate_path =~ s#^\Q$repos_root\E(/|$)#\/#;
+       $intermediate_path .= '/' if $intermediate_path;
+       $self->{path_regex} ||= qr/^\/\Q$intermediate_path$self->{path}\E\//;
        if (grep /$self->{path_regex}/, keys %$paths) {
                return 1;
        }

--

On Tue, Mar 3, 2009 at 8:30 PM, Tim Stoakes <tim@xxxxxxxxxxx> wrote:
> Michael Lai(myllai@xxxxxxxxx)@030309-17:43:
>>   After spending some hours struggling with git svn, it would appear
>> that it does not support svn projects stored in paths similar to
>> "http://foo.com/svn/repos/bar/myproject";, where "myproject" uses the
>> standard SVN tags/trunk/branches layout.  I'm currently using git
>> 1.6.1, though I tried this with 1.6.2-rc2 as well.  The resulting
>> .git/config looks something like this:
>>
>> [svn-remote "svn"]
>>       url = http://foo.com/svn/repos/bar
>>       fetch = myproject/trunk:refs/remotes/trunk
>>       branches = bar/myproject/branches/*:refs/remotes/*
>>       tags = bar/myproject/tags/*:refs/remotes/tags/*
>>
>> Yes, that's a redundant "bar" directory under "branches =" and "tags
>> =".  The issue seems to lie in git-svn doing something intelligent to
>> extract the appropriate trunk directory.  For the branches and tags,
>> however, it just takes the full URL and removes the repository root
>> (http://foo.com/svn/repos/bar) to produce "bar/myproject/{branches,
>> tags}/*".  The second effect is that "git svn fetch" will run but exit
>> quietly without actually pulling anything from the repository.  I
>> tracked down an existing thread on the mailing list from a while ago
>> (Feb 4th, title of "git-svn doesn't fetch anything"), but there was no
>> resolution.
>
> I've just run into this exact same issue.
>
>> There is a quick workaround, which was to make this change to match_paths:
>> <     $self->{path_regex} ||= qr/^\/\Q$self->{path}\E\//;
>> ---
>> >     $self->{path_regex} ||= qr/\/\Q$self->{path}\E\//;
>>
>> The additional "bar" directory gets pulled in when git-svn tries to
>> determine what paths to pull down, and tries to match
>> "/myproject/trunk" to "/bar/myproject/trunk".  I've merely put a
>> band-aid on the situation.  My perl is rudimentary at best, or I'd
>> have spent additional time to try to put in a "proper" patch, but was
>> wondering if anyone else had run into this problem and would be
>> willing to put in a fix (or point me in the right direction, that
>> works too).
>
> I messed about with disabling $Git::SVN::_minimize_url, but that seemed
> to break other things.
>
> Made worse for me was the fact that my 'bar' in the present was renamed
> from 'baz' in the past, so git-svn couldn't find it at r1. Very
> confusing!
>
> I'd like a nicer solution too.
>
> Tim
>
> --
> Tim Stoakes
>
--
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