version control systems

overviews, discussion & transitions

CVS

standard, widely used 'legacy system' with some serious scalabity + flexibilty problems. has client software for unix-likes, win32 + macOS8/9/X http://www.cvshome.org

Note that the Mac clients mentioned here are all screwy. Go To http://sourceforge.net/projects/maccvspro to get an up to date and (hopefully) usable version. Instructions for setting up are in the TechSpec (section 12, page 34 of the current version dec 2002). Note especially the requirement for CarbonLib. (And MacOS 8.6 or higher). The URL in the TechSpec is almost correct - the current version is 1.6, so use http://download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/English-North_American/Macintosh/System/Other_System/CarbonLib_1.6.smi.bin

multiplatform effort to build a gui for CVS → http://cvsgui.sourceforge.net/

see: Using CVS

darcs

distributed, patchset based system, easy to setup + configure, not too many weird filenames (was arch deliberately written to stresstest filesystem syntax?) not dependent on massive centralisaed server setup (apache/dav/neon/db/etc+). win32/unix compliable (if theres a haskell compiler around). cvs conversion scripts. how well does it handle binaries?

see: Using Darcs

subversion

attempts to deal with some of the shortcomming of cvs. http://subversion.tigris.org/

  • All current CVS features
  • Directories, renames, and file meta-data are versioned.
  • Symbolic links, etc, are supported
  • Commits are truly atomic.
  • Internationalization
  • Progressive multi-lingual support
  • Branching and tagging are cheap (constant time) operations
  • Repeated merges are handled gracefully
  • Support for plug-in client side diff programs
  • Natively client/server
  • Client/server protocol sends diffs in both directions
  • Costs are proportional to change size, not project size

reading

drawbacks

  • stapling extra legs on a dog to make an octopus

arch

“arch is a revision control system with features that are ideal for free software and open source projects characterized by widely distributed development, concurrent support of multiple releases, and substantial amounts of development on branches. It is intended to replace CVS and corrects many mis-features of that system.” http://www.regexps.com/#arch Some quick highlights of the feature list are:

  • distributed databases – each hacker or group can host their own branches. There's a global (world wide) name-space for lines of development and revisions. Branches can be formed from any repository to any other and merge operations can span repository boundaries without needing to actually duplicate the full contents of a repository at each site.
  • fancy merging – `arch' has support for various styles of history-sensitive branch merging. The way branches and patch-sets interact with distributed repositories makes it practical to distribute the responsibilities for patch-review and merging.
  • renames handled – of course file and directory renames are handled accurately. So are symbolic links and file permissions.
  • unobtrusive operation – `arch' is designed to stay out your way while making changes and rearranging files. It is designed to have a clean and self-documenting command-line interface having the finest characteristics of good Unix tools.
  • web interface – `arch' includes web tools for browsing past revisions.
  • revision library – `arch' includes tools for building a space efficient library of all past revisions, represented as ordinary file system trees.
  • very fast– when configured correctly, `arch' is quite fast.

see: ARCH for more info

aegis

“Aegis is a transaction-based software configuration management system. It provides a framework within which a team of developers may work on many changes to a program independently, and Aegis coordinates integrating these changes back into the master source of the program, with as little disruption as possible.” http://aegis.sourceforge.net/

mercurial / Hg

another DVCS

git

another DVCS developed and used for the linux kernel project. see: git notes

comments

despite its problems, cvs is in widespead production use, with clients on all major platforms. subversion + arch, currently only run on posix based systems (inlcuding gnus, bsds + osX). darcs looks interesting (runs on posix and win32)

look further into the possibility of integrating darcs into the OsX filesystem workflow using a combination of folder actions and or applescript/platypus/cocoadialog.. .

http://keithp.com/blog/Repository_Formats_Matter/

A nice and interesting email from 24 Okt 2007 on the PD -dev mailing list: 

From: 	  rosejn at gmail.com
Subject: 	Re: [PD-dev] SVN?
Date: 	24 October 2007 2:39:19 PM
To: 	  pd-dev@iem.at

There are a couple key factors in this decision that seem to be getting 
confused with each other.  I'm new to PD, but I've been using Git for 
over a year now with my own repositories.  In various consulting 
projects over the last few years I've developed with CVS, SVN, 
Mercurial, Darcs, Arch and Bazaar-ng.  There are a couple facets to the 
decision.

1) Distributed Development

The first, and I think most important, is the development model. 
Distributed development supports a different kind of collaboration, that 
I think is showing itself to be quite advantageous for open source 
software.  It lets groups of people organize themselves, get a piece of 
code working, and then it can be shared with the world.  Permissions and 
management of a central repository is no longer an issue.  It doesn't 
exist.  Instead Hans-Christoph, for example, would manage an official 
pd-extended branch that had the fully tested features, while everyone 
else could still share the latest and greatest stuff without having a 
centralized bottle-neck.

2) Personal development advantages

In git you have the whole repository locally.  This takes more storage 
space, which is incredibly cheap, but saves LOTS of time.  SVN can never 
merge as well as GIT because you don't have past versions of the 
repository to merge against.  Additionally, with git you get local 
versioning, local branching, and tons of distributed back-ups of the 
repository.  I'm always working on the train, for example, and with Git 
I can maintain a much better log of my development because I commit all 
the time without needing internet access. Branches in git, even for huge 
projects, are basically free.  In space and time.  This changes the way 
you develop.  You can make a branch for any little idea you want to mess 
with or any tricky feature you are working on.  It's quite easy to then 
merge these branches, share them with friends, update them from other's 
repositories etc.  This is a level of power and control that you can not 
get with svn.

3) User Interface

Git was originally designed to function as a back-end suite that would 
support easy to use front-end utilities.  That has changed over time, 
and it now includes a nice set of commands and tools that make it work 
just like you would expect.  For sure Git doesn't have the GUI plugins 
like SVN or CVS and it will take some learning, but I think the benefits 
in the long term will far, far outweight the initial investment.

There is a Tk interface, GitK, which is incredibly useful to visually 
look at the history of a repository, merges, branches etc.  There is 
also git-web, which lets you view the repository online.  Git also lets 
you publish a repository just by copying a directory to an http 
accessible location.  This means anyone can share their ideas, features, 
abstractions etc, without setting up a server, getting permission for a 
centralized location or anything.  Also relevant to the user experience 
is speed.  Git blows away all the other systems in terms of speed.  It 
does everything faster, and you really notice this because it changes 
what you do.  In some of the other systems, like Bazaar-ng, committing, 
pulling and pushing took so long I wouldn't do it that often, but with 
git it's all so cheap I do it every time I get a new unit test to pass.

4) Technical

Git writes the repository into a highly compressed format, and then it 
does not mess with the files.  Append only is the standard operation, 
except for when you occasionally compress the whole thing, in which case 
it can verify sanity.  It is also much cleaner to work with in terms of 
permissions and access, just because of the whole usage model.  I've had 
many experiences with subversion where the repository had to be 
recovered because of permissions issues and/or corruption.  This is very 
bad, especially since it is a centralized server that everyone is 
counting on.  It takes a root user to go in and run "svnadmin recover", 
which in my opinion is a command that shouldn't need to exist in 
something as important as a source repository.

Keith Packard who runs the X.org project wrote a very good post 
detailing his research and opinions into source control.  It's a bit old 
now, but worth the read: http://keithp.com/blog/Repository_Formats_Matter/index.html

Sorry for the long post, but this is something I have dealt with a lot 
recently.  In my mind distributed versioning is the only proper way to 
run a modern open source project.  PD is a great piece of software with 
a seemingly cool and diverse group of developers, which seems perfect 
for a decentralized model.  Either way, I think the decision should be 
made first between a centralized or distributed versioning system, and 
then the decision can be simplified to figuring out compatibility, 
usability etc.  It's great news that Git now runs on windows though, 
because I think it is far better than the others.  To quote one of 
Hans-Christoph's recent signature lines:

Mistrust authority - promote decentralization.  - the hacker ethic
  • version_control.txt
  • Last modified: 2009-03-31 09:56
  • by nik