Hi Travis: I think we have a rather similar view on the matter.
I would also prefer to go with a distributed SCM rather than with SVN, simply because a DSCM is more capable these days. For example, we tried to stay away from using CVS branches much in Invenio, but the Indico guys have been maintaining several longer-term branches in CVS and they could tell us some stories about the merging fun they are now having ;-). With SVN the branching/merging would be kind of painful too. (It may be interesting to hear from people that might have done a non-trivial merge with SVN here?) Philosophically, SVN cannot easily compete with native branching/merging capabilities offered by a DSCM concept. E.g. a nice repo view comparison of: - Git cross-branch merging: <http://utsl.gen.nz/talks/git-svn/merge.png> - SVN cross-branch merging: <http://utsl.gen.nz/talks/git-svn/merge-on-drugs.png> - Darcs vs SVN topic branches: <http://utsl.gen.nz/talks/git-svn/hydra-vs-regular.png> taken from the article <http://utsl.gen.nz/talks/git-svn/intro.html>. So, while going with an SVN might be interesting CERN-wise if, say, CERN's Savannah and CERN's SVN services get bundled one day as Marko discussed yesterday, nevertheless I think that a DSCM would be a better choice technically. (And could also be a nice choice politically to express our distributed Inspire collaboration.) As to git versus hg, I kind of like both. What I like about git is that it is more powerful if we need this power one day. (I did not find it very hard to use in my rather limited[1] experience so far.) But there are some things that bug me about git, to boot a cosmetic issue with commit changesets not being numbered linearly. For example, here is a log view from an Invenio test git repo compared to an Invenio test hg repo: $ git log -3 search_engine.py | commit 9975dbd0c8c6223a261cebb871d724331f6c2600 | Author: kaplun <kaplun> | Date: Fri Mar 14 08:35:20 2008 +0000 | | Hidden warning message when user print a jsMath enabled page | with poor fonts support on the browser. | | commit 74ea8a3913a0f22894d13c383f6982562d0067c3 | Author: jerome <jerome> | Date: Thu Mar 13 14:23:28 2008 +0000 | | Restrict record similary search to 'cc' when 'cc' is specified. | | commit 76a6d29d77c9c33c6990ece19945446c8a393e6a | Author: tibor <tibor> | Date: Wed Mar 12 16:47:32 2008 +0000 | | Updated codebase to use CFG_SITE_URL instead of weburl everywhere. | Updated client code that was shadowing this variable. (Please don't | shadow variables!) This concludes the massive CFG_* variable renaming | in the codebase. $ hg log -l 3 search_engine.py | changeset: 5329:23acbfc06e7e | user: kaplun | date: Fri Mar 14 09:35:20 2008 +0100 | summary: Hidden warning message when user print a jsMath enabled page | | changeset: 5311:c753ee658cc5 | user: jerome | date: Thu Mar 13 15:23:28 2008 +0100 | summary: Restrict record similary search to 'cc' when 'cc' is specified. | | changeset: 5294:f9e16a42368a | user: tibor | date: Wed Mar 12 17:47:32 2008 +0100 | summary: Updated codebase to use CFG_SITE_URL instead of weburl everywhere. It is so much nicer to do things like "cvs diff -r 1.2 -r 1.3 foo.py" with hg (or with bzr) than with git... [1] I don't have much first-class experience with DSCMs either; I have been using them mostly "passively" when I was interested in a software managed by them (e.g. Emacs Planner/Muse on Arch/tla (now moved to git) or Ion WM on Darcs). I have also had some test drive fun with some DSCMs, but mostly in a "one man" exploratory situation only. Best regards -- Tibor Simko ** CERN Document Server ** <http://cds.cern.ch/>
