# Re: [PATCH] git svn clone -s was not prefixing 'branches/'

4 messages from 2009-01-17 to 2009-01-18. Participants: Eric Wong, Jon Lim, Björn Steinbrink.
Thread: https://gitlist.dev/t/17223

## Eric Wong, 2009-01-17 10:54

Subject: Re: [PATCH] git svn clone -s was not prefixing 'branches/'
Message-ID: <20090117105427.GA15801@dcvr.yhbt.net>
URL: https://gitlist.dev/e/20090117105427.GA15801%40dcvr.yhbt.net
In-Reply-To: <1232050647-2870-1-git-send-email-snowblink@gmail.com>

```
Jonathan Lim <snowblink@gmail.com> wrote:
> All branches in the subversion repository would appear at the same
> level as trunk.  The should now appear with a 'branches/' prefix.
> 
> Signed-off-by: Jonathan Lim <snowblink@gmail.com>

This is too ugly for the common existing cases.  For the rare case where
this could lead to a namespace conflict[1], it's possible to work around
it by editing .git/config.

I would accept a --tags-prefix= and --branches-prefix= patch to make
this possible w/o having to edit .git/config, but I don't want the
default prefixes changed.

Thanks,

[1] - "/branches/trunk" vs "/trunk", which I've yet to see evidence of...

> ---
>  git-svn.perl |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/git-svn.perl b/git-svn.perl
> index ad01e18..17d65cb 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -789,7 +789,7 @@ sub cmd_multi_init {
>  	}
>  	return unless defined $_branches || defined $_tags;
>  	my $ra = $url ? Git::SVN::Ra->new($url) : undef;
> -	complete_url_ls_init($ra, $_branches, '--branches/-b', $_prefix);
> +	complete_url_ls_init($ra, $_branches, '--branches/-b', $_prefix . 'branches/');
>  	complete_url_ls_init($ra, $_tags, '--tags/-t', $_prefix . 'tags/');
>  }

```

## Jon Lim, 2009-01-17 11:39

Subject: Re: [PATCH] git svn clone -s was not prefixing 'branches/'
Message-ID: <751e526a0901170339m6471ac84tdb032a090d19d7c6@mail.gmail.com>
URL: https://gitlist.dev/e/751e526a0901170339m6471ac84tdb032a090d19d7c6%40mail.gmail.com
In-Reply-To: <20090117105427.GA15801@dcvr.yhbt.net>

```
Hi,

Maybe this patch doesn't fix the problem I was having. I will attempt
to describe it better here.

I understand that a standard subversion setup is as follows:
trunk
branches
tags

With the -s option, svn clone should expect this.

Using the example subversion repository:
trunk
branches/RB_1.0
branches/RB_2.0
tags/REL_1.0
tags/REL_2.0

Currently, using the -s option you get:
trunk
RB_1.0
RB_2.0
tags/REL_1.0
tags/REL_2.0

I think it makes sense to have:
trunk
branches/RB_1.0
branches/RB_2.0
tags/REL_1.0
tags/REL_2.0

Regards,
Jon

On Sat, Jan 17, 2009 at 10:54, Eric Wong <normalperson@yhbt.net> wrote:
> Jonathan Lim <snowblink@gmail.com> wrote:
>> All branches in the subversion repository would appear at the same
>> level as trunk.  The should now appear with a 'branches/' prefix.
>>
>> Signed-off-by: Jonathan Lim <snowblink@gmail.com>
>
> This is too ugly for the common existing cases.  For the rare case where
> this could lead to a namespace conflict[1], it's possible to work around
> it by editing .git/config.
>
> I would accept a --tags-prefix= and --branches-prefix= patch to make
> this possible w/o having to edit .git/config, but I don't want the
> default prefixes changed.
>
> Thanks,
>
> [1] - "/branches/trunk" vs "/trunk", which I've yet to see evidence of...
>
>> ---
>>  git-svn.perl |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/git-svn.perl b/git-svn.perl
>> index ad01e18..17d65cb 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -789,7 +789,7 @@ sub cmd_multi_init {
>>       }
>>       return unless defined $_branches || defined $_tags;
>>       my $ra = $url ? Git::SVN::Ra->new($url) : undef;
>> -     complete_url_ls_init($ra, $_branches, '--branches/-b', $_prefix);
>> +     complete_url_ls_init($ra, $_branches, '--branches/-b', $_prefix . 'branches/');
>>       complete_url_ls_init($ra, $_tags, '--tags/-t', $_prefix . 'tags/');
>>  }
>



-- 
http://snowblink.co.uk/

```

## Björn Steinbrink, 2009-01-17 12:07

Subject: Re: [PATCH] git svn clone -s was not prefixing 'branches/'
Message-ID: <20090117120723.GA24549@atjola.homenet>
URL: https://gitlist.dev/e/20090117120723.GA24549%40atjola.homenet
In-Reply-To: <751e526a0901170339m6471ac84tdb032a090d19d7c6@mail.gmail.com>

```
On 2009.01.17 11:39:28 +0000, Jon Lim wrote:
> Hi,
> 
> Maybe this patch doesn't fix the problem I was having. I will attempt
> to describe it better here.
> 
> I understand that a standard subversion setup is as follows:
> trunk
> branches
> tags
> 
> With the -s option, svn clone should expect this.
> 
> Using the example subversion repository:
> trunk
> branches/RB_1.0
> branches/RB_2.0
> tags/REL_1.0
> tags/REL_2.0
> 
> Currently, using the -s option you get:
> trunk
> RB_1.0
> RB_2.0
> tags/REL_1.0
> tags/REL_2.0
> 
> I think it makes sense to have:
> trunk
> branches/RB_1.0
> branches/RB_2.0
> tags/REL_1.0
> tags/REL_2.0

Why? "trunk" is just a branch like any other branch, too. It's basically
just a svn convention that it's not in branches/ but in its own
"toplevel" directory. Once imported into git, it's just an ordinary
remote tracking branch. It's already pretty well distiguishable from all
the other branches due to its name.

What _does_ make sense is to have a common prefix for all the stuff you
got from svn, using for example --prefix=svn/. That way you get:
svn/trunk
svn/RB_1.0
svn/RB_2.0
svn/tags/REL_1.0
svn/tags/REL_2.0

The important part is that those names aren't ambiguous if you have
local branch heads called, for example:
trunk
RB_1.0
RB_2.0

as the svn/ prefix is part of the shortname for the remote tracking
branches. So "trunk" is the branch head and "svn/trunk" is the remote
tracking branch.

Btw Eric, is there any reason why there's no prefix used by default?
Using the name for the svn-remote as the prefix would make a lot of
sense to me.

Björn

```

## Eric Wong, 2009-01-18 01:24

Subject: Re: [PATCH] git svn clone -s was not prefixing 'branches/'
Message-ID: <20090118012439.GA31969@dcvr.yhbt.net>
URL: https://gitlist.dev/e/20090118012439.GA31969%40dcvr.yhbt.net
In-Reply-To: <20090117120723.GA24549@atjola.homenet>

```
Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2009.01.17 11:39:28 +0000, Jon Lim wrote:
> > Hi,
> > 
> > Maybe this patch doesn't fix the problem I was having. I will attempt
> > to describe it better here.
> > 
> > I understand that a standard subversion setup is as follows:
> > trunk
> > branches
> > tags
> > 
> > With the -s option, svn clone should expect this.
> > 
> > Using the example subversion repository:
> > trunk
> > branches/RB_1.0
> > branches/RB_2.0
> > tags/REL_1.0
> > tags/REL_2.0
> > 
> > Currently, using the -s option you get:
> > trunk
> > RB_1.0
> > RB_2.0
> > tags/REL_1.0
> > tags/REL_2.0
> > 
> > I think it makes sense to have:
> > trunk
> > branches/RB_1.0
> > branches/RB_2.0
> > tags/REL_1.0
> > tags/REL_2.0
> 
> Why? "trunk" is just a branch like any other branch, too. It's basically
> just a svn convention that it's not in branches/ but in its own
> "toplevel" directory. Once imported into git, it's just an ordinary
> remote tracking branch. It's already pretty well distiguishable from all
> the other branches due to its name.

Yup, you said it better than I could myself :)

> What _does_ make sense is to have a common prefix for all the stuff you
> got from svn, using for example --prefix=svn/. That way you get:
> svn/trunk
> svn/RB_1.0
> svn/RB_2.0
> svn/tags/REL_1.0
> svn/tags/REL_2.0
> 
> The important part is that those names aren't ambiguous if you have
> local branch heads called, for example:
> trunk
> RB_1.0
> RB_2.0
> 
> as the svn/ prefix is part of the shortname for the remote tracking
> branches. So "trunk" is the branch head and "svn/trunk" is the remote
> tracking branch.
> 
> Btw Eric, is there any reason why there's no prefix used by default?
> Using the name for the svn-remote as the prefix would make a lot of
> sense to me.

Backwards compatibility; and that I've been lazy :)

But I do agree that prefixing "svn/" is preferred for tracking new
repos.  I seem to recall that git-svn was actually the first user of the
"remotes/" namespace before it was adopted by the rest of git, and with
SVN, I didn't anticipate more than one remote.

-- 
Eric Wong

```
