On Wed, Oct 14, 2009 at 2:00 PM, Eric Wong <normalperson@xxxxxxxx> wrote: > Avery Pennarun <apenwarr@xxxxxxxxx> wrote: >> I've been thinking about this myself for some time. One option that >> might be "interesting" would be to just grab the *entire* svn tree >> (from the root), and then use git-subtree[1] to slice and dice it into >> branches using your local copy of git (which is fast and uses no >> bandwidth) instead of during the svn fetch (which is slow and uses >> lots of bandwidth). I think it would also simplify the git-svn code >> quite a lot, at least for fetching, since there would always be a >> global view of the tree and SVN things like "copy branch A to tag B" >> would just be exactly that. > > This was actually the original use case of git svn back when I started. > > git svn clone SVNREPO_ROOT (without --stdlayout) > > It's still an option if you have the disk space for the working copies, > but I had to create the branches/tags support since the working copies > would be become prohibitively large. If git-subtree could be > taught to work on a bare repo (git svn has a --no-checkout option) > it might be an option, too. I've never tested git-subtree without a working tree, however, it doesn't *use* the working tree for anything when splitting, so at worst, there might be a minor bug or two. Thus, there ought never be a need to check out the whole huge tree (which I agree would be both slow and huge). dcommit might be a little weirder. Though I guess if we fixed the git-svn-id tags in the split branches, you could just commit directly into a branch, then fetch the new commit back from the root, then rebase the branch, as dcommit already does. You know, maybe this is actually easier than I thought... I was thinking committing back to svn would be complicated since it requires a working tree, but if we let you commit straight from one of the branches, it shouldn't actually be too bad at all. Hmm. Have fun, Avery -- 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