Certainly I favor a move away from CVS, as it seems to be a reasonable opportunity, and a good time to leave CVS.
At SPIRES we've been using SVN for a while, with no major complaints, hence my initial reaction was to favor SVN for inspire/invenio work. However, after reading a bit about distributed paradigms, I think these might fit rather well, and I'd be interested to try them. I should mention 7) SVK which is maintained now by Best Practical, which also does RT, and is somewhat of a bridge from the SVN file system to the distributed paradigm. Also note this interesting blog: http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/ Things important to me would be, in order: 1) Relatively mainstream (i.e. integration with IDEs, ease of migration/adoption, stability, lack of "funny looks" from other folks...) 2) Ease of use (i.e. shouldn't be a headache to use SCM just to get one "cool" feature) 3) Distributed paradigm (i.e. use of local repos for small projects, making branches easy, etc.) infty) Speed (i.e. this seems like a non-issue for this size of project and the way I generally work.) This seems to me to point toward hg or git, and hg seems to score a bit on ease of use (as does bzr). However, people with actual experience with some of these should be taken more seriously than I. Best, Travis On Mon, 2008-03-17 at 12:31 +0100, Tibor Simko wrote: > Hello fellow Indico, Invenio, and Inspire developers: > > As you may know, our CVS repository is hosted on an aging machine that > we are progressively moving away from. The forthcoming Invenio 0.99.0 > release will provide us with a very good opportunity to migrate the > CVS repository onto a more recent hardware. > > Moreover, we can take advantage of this move in order to possibly > upgrade our SCM system too. We started to discuss such an upgrade in > 2004 already, but we decided to stick to CVS at that time, the CVS > being CERN-wide SCM. I think the time has come to reevaluate the > options once again. > > Here is a short overview of our principal options: > > Centralized SCM paradigm: > > 1. CVS > > - moving to CVS hosted on another box is an obvious candidate > - nothing changes for developers; we only need to obtain firewall > opening for the new machine > - but we would be stuck again with all CVS problems that are often > as basic as proper file renaming > > 2. Subversion (svn) > > - natural evolution of CVS centralized SCM paradigm > - adopted by many big projects since years > - small adaptation/learning curve needed > - CERN might be deploying a central SVN service in 2008, so we may > eventually use this central service later (this can be seen both > as a plus and as a minus) > - but merging capabilities not really much better than with CVS > - but tagging capabilities can even be worse than with CVS > > Distributed SCM paradigm (may fit better our more and more distributed > development environment): > > 3. Git > > - adopted by many big projects (besides Linux kernel) > - featureful and powerful > - but also more complex; possibly steeper learning curve from CVS > - but not running very well on MS Windows (which can be seen both > as a plus and as a minus) > > 4. Mercurial (hg) > > - cleaner and simpler git-like alternative > - possibly smoother transition from CVS > - written in Python, so easy to run everywhere (e.g. it was no prob > to create a recent RPM for the aging SLC4 OS in a minute) > - easy native transport setup over HTTP > - but less powerful than Git > - but less mainstream adoption than Git (but e.g. Mozilla) > > 5. Bazaar (bzr) > > - like Mercurial, written in Python too > - recently became an official GNU project; e.g. GNU Emacs seems to > be going to adopt it to replace its CVS > - used to be much slower than Mercurial, but it's catching up > > There are other interesting choices such as 6) Darcs that, as you may > recall, I liked in 2004, but nowadays there are perhaps more > "mainstream" alternatives in 3-5. > > Some issues to have in mind: > > a) other personal projects: distributed SCM can be used easily for > other local hacks too, so it may be nice to standardize upon one; > can retain a notion of "central" repo > > b) transfer channel: HTTP/HTTPS read/write transport channels do not > require official firewall port opening and local users and stuff, > so it's easier to (i) hop on various machines and (ii) to be > "different" from the main CERN SCM tool (currently CVS, soon > probably SVN) > > c) integration with IDEs: to take Emacs an example, the native > version control ("C-x v *") supports all these alternatives well, > with Git, Mercurial, and Bazaar natively only from Emacs 23 > > d) OS dependency: if we host the repo, it should be easy to install > very recent SCM versions on an aging OS such as SLC4 > > For more musings and pros/cons of various systems, you can check out > e.g. Elijah's recent blog posts: > <http://blogs.gnome.org/newren/2008/03/01/happenings-in-the-vcs-world/> > <http://blogs.gnome.org/newren/2007/11/17/adoption-of-various-vcses/> > > Please think of this email as a kick-off to stem some discussion and > compare our preferences... > > Best regards -- Travis C. Brooks <[email protected]> Stanford Linear Accelerator Center
