GNU Arch

Hans Fugal hans at fugal.net
Tue Mar 8 08:03:17 MST 2005


On Mon,  7 Mar 2005 at 15:27 -0600, brett.rasmussen at twoedge.com wrote:
> I also looked into darcs a little bit, and my feeling was that it did
> the distributed repositories and merging very nicely. And I got the
> feeling its user interface was simpler than arch's. But I felt it
> wasn't as mature or well documented, and its merging algorithm gave me
> worries about the possibility of extreme memory consumption.

I'll pitch in for darcs, which I use exclusively on my own projects now.
I previously have used cvs (of course) and svn, and I tried tla (tom
lord's arch) once.

Darcs' user interface _is_ simpler than arch's. This is a _good_ thing.
There's no reason distributed version control has to be black magic and
completely unusable, which is my opinion of tla. That it is simpler does
not mean it is limited. 

I don't know where you were looking for documentation (or when), but I
spent at least an hour trying to figure out where the best arch docs
were, and the excellent darcs docs are right there on the website. 
The darcs man page is excellent, as is command-line help for the whole
suite or just that command, a la CVS. e.g.:

    $ darcs get -h
    Get a repository.

    Options:
	--repo-name=DIRECTORY  path of output directory
	--partial              get partial repository using checkpoint
	--complete             get a complete copy of the repository
	--to-match=PATTERN     select changes up to a patch matching PATTERN
	--to-patch=REGEXP      select changes up to a patch matching REGEXP
	--tag=REGEXP           select tag matching REGEXP
	--context=FILENAME     version specified by the context in FILENAME
    -v  --verbose              give verbose output
    -q  --quiet                suppress informational output
	--standard-verbosity   neither verbose nor quiet output
	--set-default          set default repository [DEFAULT]
	--no-set-default       don't set default repository
	--disable              disable this command
    -h  --help                 shows brief description of command and its arguments

    Get is used to get a local copy of a repository.


The darcs author has impressed me as really knowing his stuff on the
theory - not just some hacker that decided to make a version control
spinoff. That makes me sleep easier.

Darcs uses one directory, in the root of your project, called _darcs.
No pollution of your home directory (tla) or special repository
locations (cvs and svn). Need a copy of a darcs repository? cp, scp, rsync, or
any other method will work just as well as the traditional darcs get command
(although that gives you more fine-grained control).

You probably got the memory concern from the author's disclaimer on his
website, at least subconsciously. I think he's being modest, or careful,
or both. I haven't tried it on large projects yet, but on the small ones
it is just fine. I know there is a kernel darcs repository, so if you
want to see how it performs on the big stuff that's an option. If it
would make a difference to anybody, I'd be happy to give that a try and
report back.
 
But really, what's more important than whether you use darcs or tla or
one of the handful of other distributed version control systems, is that
in many cases it is a much much better way to work, especially for open
source. You owe it to yourself to at least see what this new paradigm is
all about; you won't understand what's so cool about it until you
immerse yourself in it for a bit. If you need egging on: Linus cares,
shouldn't you?

-- 
 .O.  Hans Fugal            | De gustibus non disputandum est.
 ..O  http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
 OOO                        | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95  CB5E FC98 E8CD E0AA D460
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20050308/4f52be91/attachment.bin 


More information about the PLUG mailing list