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