I've been tinkering w/git submodules and it really is a killer feature for the typical eCos application we work on:
- we'll clone eCos repository and keep a modified version of that repository on our servers. Here we track various modifications in eCos until those modifications eventually make it back into the official eCos tree, or for those modifications that never should be made part of the main tree we keep it on our servers. This eCos repository is shared between clients/projects. - we'll clone the eCos repository onto *our* server in-house, yielding super fast checkout times. (git submodule update). This also does not waste bandwidth of official servers. - git submodules are also used for other eCos repositories that e.g. keep a specific HAL or some other feature. - this also works fine w/projects that use svn as a server, e.g. libmicrohttpd which is a module we use, but it's not actually an eCos project. - when various people work on the same project, we don't have to write scripts to set up the build enviornment. It's clone + submodule init + submodule update => voila! At this point I have no idea what happens when throwing mercurial into the mix here, but "easy" isn't the first word that comes to mind :-) When choosing DVCS I hope that non-trivial operations are considered more than trivial ones. Trivial operations, like cloning, is trivial with git & mercurial both. For the most trivial operations downloading and untarring is probably the way to go rather than introducing version control at all. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
