jiho wrote:
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 ;) ):
I think this would be a great time to encourage DVCS usage among the developers. But until a number of us have some experience from which to speak about the products, making a decision to use one would make me nervous.
As you may know a few people are already using DVCS systems to do their work on inkscape. Ted uses SVK (you can tell by the number of times that his commit messages say "SVK screwed up the last commit" :-) ). Mental uses git-svn (he described his use of git-svn for jruby at http://moonbase.rydia.net/mental/blog/programming/using-git-svn-for-jruby). I've heard that a similar workflow is possible with bzr (http://bazaar-vcs.org/BzrForeignBranches/Subversion). I have not heard anything of hg but I would expect something similar. We can try these tools now, without switching over the entire repo.
Having said that perhaps there is some worth in switching now.
-- 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
- supports renames (could be considered a Bad by git users) - supports bundling changesets -
Bad
Aaron