[Haskell-cafe] Re: a newbies confusion with repositories - darcs or git

[Eric Kow]

Hi again,

I wanted to echo Iavor's comment that you shouldn't feel 'obliged' to
use darcs out of Haskell brand loyalty.

Try both systems out and see how they feel.  My enthusiasm is really
about what I find to be a great and very comfortable workflow.  You'll
have to see for yourself what suits you best.

More importantly...

On Sun, Mar 01, 2009 at 10:40:46 +0000, Eric Y. Kow wrote:
> Why I love darcs
> ================

One of the darcs team members, Thorkil Naur, felt that in my enthusiasm I
was not being sufficiently forthright about darcs's shortcomings.

First, I would like to express my gratitude to Thorkil for calling me
out.

Second, I wanted to state unequivocally that darcs, no matter how much I
love it, is not perfect.

> It's not just that it's written in Haskell; it's that the whole thing
> is driven by something which is very clean, powerful and which
> delivers a concrete impact in the real world.

When I said this, I was focusing on one idea: namely that most of the
darcs user interface is just as straightforward consequence of two
operations: patch inverse and patch commutation.  In my eyes, that was
very clean, the whole of darcs basically just boils down to these two
operations.

What I failed to add is that /defining/ how patches should commute is
not so beautiful.  The problem occurs when patches conflicts; the
question of how patches should commute when they conflict is still not
completely well understood.  We have some working ideas: code for
darcs-1 and darcs-2 patch theories which seems to work reasonably well.
But to call it clean and elegant would definitely be a stretch.

Furthermore, darcs has bugs, some of which are fairly deep (where
conflicts or duplicate patches are involved).  Some of these bugs are
documented and some we have only recently discovered, and some may be
looming just around the corner.  So far, these bugs have not affected a
lot of repositories, and in those cases, it has been fairly
straightforward to recover from them.  But know that they are there.

> We now have a stable and more sustainable development team (I'm working on 20%
> darcs time at my job with the University of Brighton and have committed myself
> to spending no more than 8 hours a week on darcs to avoid burnout; a lot of our
> jobs have been assigned to dedicated managers -- hello!) and are adopting some
> new practices (hacking sprints, 6-month time based release schedule) to keep
> development running more smoothly.

Another reason to be concerned about the darcs team is that since David
Roundy retired from darcs life, we do not have anybody who deeply
understands darcs, that is, all the way down to the inner workings of a
darcs repository (for example the manipulation of the pending patch) and
to its patch theory core.

We have folks like me who have a rudimentary understanding of patch
theory (i.e. who grasp the relationship between commutation, inversion
and merging and who also understand some of what darcs-1 conflicts are),
but what we lack are people who deeply understand the darcs-2 core (Ian
Lynagh's work on camp is actually quite similar to darcs 2, so in a
sense, he does understand it), especially as it's implemented.

This puts us in an awkward position, one of not being able to quickly
work through any fundamental bugs if they should arise.  We would have
to scamper up that learning curve fairly quickly.

But I'm still optimistic over the long term.  These things will come.
We've made a lot of progress building up our community infrastructure, 
and we are learning how to make better use of our time.

For what it's worth, a few of us on the team will be focusing on darcs
fundamentals during the sprint.  We need more testing, we need to look
at our deep bugs more closely and we need to learn our way through
darcs's guts.  And I think we can do it.

Thanks,

Eric

PS. We have started a fundraising effort to get folks to the darcs
    hacking sprint.  More details on that shortly.
 
-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090307/f2d4bf17/attachment.bin