[Haskell-cafe] New book: Real-World Haskell!

Jason Dagit dagit at codersbase.com
Tue May 29 21:58:43 EDT 2007


On 5/29/07, Doug Kirk <doug at dkirk.com> wrote:
> OTOH, I work for companies, and they really value their assets,
> especially software assets. So they *want* centralized stuff, so they
> can ensure they have consistent backups (in the U.S.A. there is a lot
> of regulation under Sarbanes-Oxley that requires this stuff). Right
> now we're using ClearCase, which I abhor because it's so
> heavyweight...but it is centralized control.

Interestingly, using a decentralized version control does not rule out
the possibility of centralized control and development.  For example,
darcs itself has a very centralized development even though the tool
allows decentralization.  The advantage is that people working on, for
example, a feature branch can easily share patches via cherry picking.
 When the feature branch is ready to be merged darcs handles this in a
way superior to svn[1] by doing the merge almost completely
transparently.  We're currently developing a feature branch at work
under svn and every merge is a book keeping headache and at least one
day of lost development time.  In this respect, svn seems primitive,
tedious and error-prone.  Just check the svn red bean book for details
on merging in svn.  We have learned you need to manually track version
numbers so you don't merge things twice.  Perhaps my argument is more
about svn vs. darcs, but those are the two version control systems I
know best.

[1] I will happily concede that darcs is not currently perfect in it's
automated merging, especially in the case of conflicting patches.
Just ask the ghc developers if this is a problem for them.  But, that
is also why there is a summer of code project this year to fix the
problem.  With a fair bit of retooling, darcs will handle this case
better in the future and I'm confident this will become a problem of
the past.

Jason


More information about the Haskell-Cafe mailing list