On 2008-March-14 , at 06:54 , Bryce Harrington wrote:
[...] Now, architectural reworkings can often risk incur massive breakages since fundamental pieces of the code are being changed. In order to minimize this, I'd like to suggest the following principles:
- Always keep the tree buildable
- Do major refactorings in small steps
- Hold code review parties with 2-3 others to brainstorm
- Drop copied-in codebases in favor of external dependencies
- Make sure every function you touch has some doxygen comments
[...] This schedule permits us to focus exclusively on refactoring for several months, with a due date of July 1st to complete it. It uses a very early branch point, where we'll split into a stable branch for doing bug fix and release work, and a development branch for the GSoC students to use and for folks to continue right on with refactoring projects if they wish.
Since this supposes a lot of branching (for SoC, probably also for many large scale changes because the tree still needs to be usable during that time etc.) wouldn't it be a good time to change version control system to something that eases branching and merging? Plus, distributed version control would ease a model where changes are reviewed by several people before they are committed to the main tree (i.e. just pull the changes from other people's trees and allow commits to the main tree only by the reviewers). The discussions on the list about this are old and quite long and to summarize them in a few words: - everybody agreed that there are solutions superior to svn in all point of views - the contenders are git, mercurial and bazaar - all of them are pretty equivalent in terms of basic functionality now - compare to basic svn usage (update, status, diff, commit, log) all of them should be close enough so that they don't demand much learning by developers used to only svn - in all of them it should be possible to hook a check mechanism after each commit (which would probably prove very useful in the context of re-factoring to check the changes for 'make check' passing or other custom test suite)
Now for the specific benefits/problems associated which each one (I know git a little, not the others, so please fill in the blanks and correct my mistakes so that we can come up with a clear list to decide from (or not ;) ):
-- GIT ---------------------------- Good - very fast (but anything would be faster than svn anyway) - allows to stash away local changes to fix a small issue. probably useful when, in the middle of a large code change, one notices a local bug which does not have anything to do with the change (not sure this is git-only) - ability to follow chunk of codes around, without relying on file names. Probably useful from a refactoring point of view - probably the fastest growing user base => many tools
Bad - does not run too well on windows
-- HG ----------------------------- Good
Bad
-- BZR ---------------------------- Good - already integrated in launchpad
Bad
JiHO --- http://jo.irisson.free.fr/