[crossfire] crossfire source code control systems
Raphaël Quinet
raphael at gimp.org
Tue Aug 22 09:44:53 CDT 2006
On Tue, 22 Aug 2006 10:28:24 +0200, Tchize <tchize at myrealbox.com> wrote:
> I did not follow this thread, but am curious on this point on the wiki
> page. It's stated 'good branch handling' on CVS and SVN as no. Am sorry
> to raise it now, but i have been using branching on CVS at work for a
> while and we never had any problem with branching.
I would like to second that. As a GIMP developer, I have been using
CVS branches extensively: we always maintain HEAD together with at
least one stable branche, while several experimental features are
developed in their own branches, such as the recent Google Summer of
Code projects. We also perform a lot of merges from the HEAD branch
to the stable branch and sometimes from the stable or experimental
branches to the HEAD branch, as you can see in the ChangeLog from the
stable branch: http://developer.gimp.org/ChangeLog-2.2
So regardless of how the different systems support branching and
merging, I think that the support offered by CVS and SVN is good
enough in practice, including for large projects. So all systems
would get 1 point there.
[...]
> In fact, reading the wiki page, svn has all the request and all the nice
> to have features (bringing a total of 20 and a total2 of 36.5)
I think that the scores could even be adjusted further:
- The "learning curve from CVS" has not been taken into account. This
should not be underestimated. This would probably deserve more than
1 point (which would be given to CVS and SVN). By the way, I do not
think that Bzr or Mercurial are really easier to learn than Darcs
(or Arch or Cogito/git), but that is of course subjective.
- The popularity of each system should also be taken into account, for
two reasons: using similar tools would be better for those who work
on several projects (daimonin, cfplus, cf-extended, or other
projects from GNOME, KDE, Xorg, various Linux distributions, etc.)
and using a popular tool means that it is easier to get support or
to switch to a different host in case there is some problem with the
current host of the repositiory. Again, CVS and SVN would get an
extra point here.
> Another fact that was not taken into account it the fact sourceforge
> hosted revision control has the advantage of not having to duplicate
> user accounts. You can use the same accounts for revision control, bug
> tracking, releasing, web management, and project admins can manage all
> that using a single interface.
Indeed, this is also an important point. The integrated support for
releases and downloads is not too critical because it only concerns a
small subset of the developers (often a singleton) but having good
links between the bug/patch/request tracker and the source code
management system is a big plus for most developers. So the systems
supported by SourceForge get an extra point here. I also like the way
the GNOME and KDE projects have nice cross-references between the
Bugzilla entries and the corresponding CVS or SVN changes: commit
messages mention bug numbers that will be automatically linked to the
bug reports in the viewcvs/viewsvn interfaces, and the comments
closing the bug reports include the corresponding commit message.
> The best solution to decide will probably be a vote amongst commiters as
> everyone probably has it's preferences.
Yes, because although the matrix is nice, it does not and cannot
accurately reflect the opinions of all developers: some reasons why
some developers would prefer some systems over another may not have
been stated yet in this discussion, or maybe they have been stated but
not included in the matrix (for example, I suggested to rate the
support for partial checkouts and for partial updates).
Also, some developers may think that some features are more important
than others and give them more weight. For example, I think that the
support for renames is a "top feature" or maybe even a "key
requirement" rather than "nice to have" because this could be very
useful when renaming map directories (and being able to track the
changes across branches and merges). I would therefore count more
than one point for this feature. Same for the availability of hosting
services like SourceForge, which is worth more than 1 point according
to Mark's TOTAL2 formula in which the weights are 2, 1.5 and 1.
So if I take into account all the changes mentioned above and promote
or demote some features accordingly, I end up with a rather different
table:
CVS SVN Hg BZR DARCS
Key Requirements (11) 10 10 6 8 8
Top Features (7) 6 7 5.5 4 4
Nice to Haves (6) 3 5 6 6 6
TOTAL (24) 19 22 17.5 18 18
TOTAL2 (38.5) 32 35.5 26.3 30 30
Now we get a totally different picture: SVN comes on top, followed by
our good old CVS, then come Bzr and Darcs, and then only Mercurial.
Of course some may claim that the updated table is biased, but that's
the whole point! I give more weight to the features that I consider
more important: availability of hosting solutions (multiple choices if
possible), support for renames, support for partial updates, etc.
Others may have different priorities and that's fine for me. The
current table is probably biased toward what Mark or Alex consider
as being important. If there was a vote, this updated table would
help me to decide how I would vote. Others with different priorities
would probably vote differently.
-Raphaël
More information about the crossfire
mailing list