On 7/5/2010 8:16 PM, Greg Troxel wrote: > > You have found the core issue with svn/git: svn allows you to have a > large repo with everything (and atomic commits across it) and to have > users check out parts of the repo separately. git does not, because the > svn separate checkouts model only works with a remote repository that > you don't keep a copy of. With git, cloning the repo gets you the whole > thing. Makes sense. > One thought is that you may want to separate how you organize boost > sources in git and how you release them. It's possible to have a single > git repo for all libraries and have atomic commits but then create > distfiles for each library separately. > > git becomes a bit slow when ... <snip> It can't get any worse than svn. We haven't run into any perf problems with git yet. That's not our primary concern. > My advice (which is not really about git) is to figure out whether you > want: > > A) a set of interrelated libraries on which you will allow atomic > commits that change interfaces/usage in multiple libraries > > or > > B) a set of independent libaries which have commits to separate > libraries, and for which you insist that each library have an API and > ABI compatiblity story, so that even when upgraded other libraries can > continue to use it. > > > For A, you probably want one git repo, much as you have one svn repo > now. For B, multiple git repos are the right answer. I'll take B FTW! :-) The idea is to open up and distribute C++ library development. Versioned dependency tracking will be handled at a higher level with per-project metadata and a tool (pip) that resolves dependencies. API compatibility is handled with peer review and regression testing. ABI compatibility is not an issue because we're distributing source code. -- Eric Niebler BoostPro Computing http://www.boostpro.com -- 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