New Source Code Management Systems

 "Michael" == Michael Bond <[email protected]> writes:

  Michael> Perhaps you could outline the advantages of darcs for the
  Michael> group.  If anyone else has another system that they enjoy
  Michael> using, please let us know. The only revision control system
  Michael> that i really know is CVS, which is a beast to use but
  Michael> time-tested and proven.

OK, I can't speak for everyone, but here are the things I want in my
SCM, not in any order:

(0) Freedom: Must be Free Software Compatible. This is always a
    requirement for me.

(1) Disconnected: I don't want to have to have a server; i.e. I want
    to be able to work disconnected and also be able to have a central
    place for other developers to share.

(2) Independence: I want to use the same SCM as the developers of a
    given program to work on my modifications without being an
    official developer.

(3) Integration: I want it to integrate really well with my work-flow,
    esp. my IDE.

(4) Simple: I want it to have an easily understandable mental
    model. Note, I don't care so much about difficulties at the
    command line because I expect (3).

(5) Unification: When I merge between branches, I want to easily pick
    and choose particular changes.

All of the SCMs in question pass (0), so that's no big deal. CVS
sucks. Arguments for this on the web are abundant. Just start reading
about any of Subversion, Arch, or Darcs, and they'll tell you all
about what's wrong with CVS.

Subversion does great for (3) and (4), but it's not so good at the
others.

Arch is great for all of the above except (4): it's needlessly hard to
understand.

Darcs satisfies all of the above very nicely. It really shines at
(4). It's just as good as Arch for (1), (2). I think it is even better
at (5) because of it's patch theory approach, which allows it to not
only think in terms of changesets (atomic collections of patches) but
to find dependencies between changes automatically, allowing automated
cherry-picking instead of the Arch approach that requires either a
human to know what patches should be merged.

Darcs's main problems are that it is younger than Subversion or Arch,
and it is written in Haskell which I applaud for choosing a language
that suits the problem well, but because of it not being a popular
language, it is harder to find people who can work on the
software. Then again, though, Paul Graham argues very convincingly
that uses the right language for the job is a better approach than
following the pack over the cliff.

It should be noted that in several documents on the web, moving from a
centralized system like CVS or Subversion to a decentralized system
like Arch or Darcs shifts the problem of integration away from the
software (repository) and onto the developers. This is false. A
decentralized system can trivially be used the same way as a
centralized system with the added benefits that it provides for (1),
(2), and (5) generally better.

Anyway, you should give them all a try, but if you don't have time for
that, I'm fairly certain you try out and understand Darcs in about
five minutes. It really simplifies the whole mess.
-- 
  David D. Smith
A man without doubt is a monster.

_______________________________________________
Morlug mailing list
[email protected]
http://mailman.morlug.org/mailman/listinfo/morlug

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCTNNdEJGOueZRHH4RAt5fAKCt7AaKM1FZ1t8j6Txtylfb4Y+nYgCfV08T
qGMUktYcpFcvzM9AXWtDHqM=
=lnbF
-----END PGP SIGNATURE-----