Hi, see my reply inline:

On Tuesday, May 28, 2013 6:36:43 PM UTC+2, Quark wrote:

> Hello Thomas,
> you got some serious volume of stuff there, allow me some time to 
> assimilate em
> 1) agreed, though editing in vim is just so quick

Could be. But git-svn internals go beyond the config file. There are 
remotes and various other files set up when you initiate a git-svn clone. 
Please stick to using the commands as that is what the authors of the tool 
expect us to use.

3) I am not complaining about performance, as in CPU cycles, git is beyond 
> my expectations there. I am the only odd out here, everyone else is too 
> happy about tortoise UI. Hence, sharing is not too high on my TODO list.

That's good, that should make everything easier.

> I understand svn-cloning on *nix OS, and git-clone elsewhere. As I already 
> said we have multiple projects in same svn repo and I don't want all of 
> them, I am afraid local git repo might exceed 5GB if I attempt so. Our svn 
> repo layout is something like
> <url>/branches/project000_v1.1
> <url>/branches/project000_v1.2
> <url>/branches/project111_v1.1
> <url>/branches/project111_v1.2
> <url>/branches/project222_v1.0
> and I am interested in only say project222 and its versions

I see. There are some tricks you can do for cloning svn-repos with 
non-standard structures. For example, you can do:

 git svn clone -T trunk/project222 -b branches/* --ignore-paths "
branches/project111_v1.2" srcroot

This should create a clone with the contents of srcroot/trunk/projects222 
as master/trunk branch, and branches for each folder inside branches, 
*excluding* the ignored paths, which are a perl regular expression. You 
should be able to extend this to exclude all the folders that you don't 
want branches for (I'm no regexp guru, so I'll refrain from trying. See here 
for more 

I also recommend that you add the -rN:HEAD argument, where N is a hundred 
revisions or something back in time, just to make sure the clone works 
correctly. This should speed up your test runs. Then drop the -r argument 
when you want to clone the entire history. 

> Even if I svn-clone on *nix OS, then after git-cloning on my workstation, 
> I need it to work with git-svn, thus I will issue something like "git svn 
> fetch -r BEGIN:HEAD.
> This again will have to incur network latency for each revision. From your 
> response, it looks like this the norm :(

Once you have a proper git-svn clone, you can update it with newer 
revisions coming from SVN using "git svn rebase". This is more or less just 
as fast as an "svn up".

Another technique that comes to mind regarding the complex branch cloning 
above: If you just want to clone trunk and a couple of branches, you could 
just clone each of the directories:

git svn clone srcroot/trunk/project000
git svn clone srcroot/branches/project000v1.0

and so on.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to