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 help<https://go-dvcs.atlassian.com/display/aod/Advanced+git-svn+options> .). 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
