On Mon, Jul 05, 2010 at 10:16:36AM -0400, Eric Niebler wrote: > I have a question about the best approach to take for refactoring a > large svn project into git. The project, boost.org, is a collection of > C++ libraries (>100) that are mostly independent. (There may be > cross-library dependencies, but we plan to handle that at a higher > level.) After the move to git, we'd like each library to be in its own > git repository. Boost can then be a stitching-together of these, using > submodules or something (opinions welcome). It's an old project with > lots of history that we don't want to lose. The naive approach of simply > forking into N repositories for the N libraries and deleting the > unwanted files in each is unworkable because we'll end up with all the > history duplicated everywhere ... >100 repositories, each larger than 100Mb. If the libraries are not independent (i.e. some commits are across multiple libraries), submodules will give you some interesting challenges to put it mildly. The current boost 1.43 is 29344 files, is this all there is? This should fit eaily into a single repository. The Linux kernel is much larger, and that is sort of the canonical single repo git project. I _strongly_ recommend that you go for a single repo if you can make it work. If you manage to create a single git repo with the history you want, it is trivial to split out separate repositories of subdirectories later (and those repos will then be comparatively small). git subtree allegedly automates this process more or less (I have not used it, but have heard good things about it). What about having a single "master repository", and then using subtree to create single-library repos for the library developers if they want a smaller repo to play around in? > So,, what are the options? Can I somehow delete from each repository the > history that is irrelevant? Is these some feature of git I don't know > about that can solve this problem for us? How do you define "irrelevant"? Do you only require enough history for git annotate/blame to give correct results? Or does this only refer to multiple repositories sharing the same ancient history? > At boost, We've already discussed a few possible approaches. Feel free > to comment and/or criticize any of the solutions suggested here: > > http://github.com/ryppl/ryppl/issues#issue/4 It is unclear from the discussion if you will change to git, or use git in addition to svn? This will have some impact on how to go about this. - Finn Arne -- 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