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
> 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 "
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
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
For more options, visit https://groups.google.com/groups/opt_out.