On Tue, Apr 08, 2014 at 04:43:29PM -0400, Maurizio Vitale wrote: > I've never used multiple git repositories in large scale > multi-committer projects (the closest is a new language frontend for > llvm that uses submodules for beinging in clang and llvm, but I'm > the only committer). > > I see people advocating splitting large code bases into multiple git > repository and then using one of the mechanisms suggested in this > thread to 'federate' the different repositories. > How do people handle atomicity of commits that span multiple > repositories (e.g a library and its clients)? > How do you review CLs spanning multiple repositories? > Are those problems only theoretical and don't happen in practice?
Well, the question you need to ask yourself is if you REALLY need atomicity of commits against different projects/repos! I'd say it depends on how you structure your work. If projects are loosely coupled, and released (semi-)independently then maybe just maintaining a record of what set of versions of each project work together is enough. That is, you here glide away from VCS, Version Control system, to CMS, Configuration Management System. In the places I've worked where multiple repos has been used to build a single product this tracking was tied to the continuous integration system. Where changes were required both in libs and applications (or both client and server) this was tracked via a bug tracker, simply because the organisation was so big that it very rarely was the same developer implementing both sides. The teams were in charge of their own planning so it would have been neigh impossible to get the implementations of both sides into the same changeset anyway. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay
pgpawRoD9THio.pgp
Description: PGP signature
