[Haskell-cafe] a newbies confusion with repositories - darcs or git
Gü?nther Schmidt
now that I'm finished with my haskell app I take the opportunity to
follow up on some things I hadn't quite understood in my so far short
venture into the haskell world.
Means: Prepare for a number of naive posts to follow.
I had the impression that darcs was the preferred repository for
haskellers, but there also is git.
So far I've just been using the goodol' svn.
But since I have the ambition to become a real haskeller I was gonna
make myself acquainted with darcs. Should I skip that and head straight
for git?
Günther
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Gwern Branwen
> Hi,
>
> now that I'm finished with my haskell app I take the opportunity to follow
> up on some things I hadn't quite understood in my so far short venture into
> the haskell world.
>
> Means: Prepare for a number of naive posts to follow.
>
> I had the impression that darcs was the preferred repository for haskellers,
> but there also is git.
>
> So far I've just been using the goodol' svn.
>
> But since I have the ambition to become a real haskeller I was gonna make
> myself acquainted with darcs. Should I skip that and head straight for git?
>
> Günther
I would go for Darcs. It is the standard VCS for Haskellers; a few do
use Git, but it's nowhere near the majority or even a reasonable
fraction (locally, I have copies of 12 Haskell git repos ; but I have
hundreds for Darcs).
--
gwern
Colin Paul Adams
Gwern> I would go for Darcs.
Any advantages over Perforce?
I use it at work, and find it great. So I'm using it at home too.
--
Colin Adams
Preston Lancashire
Erik de Castro Lopo
> Any advantages over Perforce?
I have used Bzr, CVS, Darcs, Git, Hg (Mercurial), Perforce and SVN.
While Perforce is definitely better than CVS (anything is better than
CVS), Perforce's client workspace concept is a bad idea for complex
projects (it bit my group of 4 developers time after time).
Compared to the DVCSs above (Bzr, Darcs, Git and Hg) Perforce has
no significant advantages and on significant disadvantage, cost.
Yes I know there is a free as in beer version, but all of those
others are available under official Open Source licenses.
HTH,
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Perl as a language has less a design than a thousand special
features flying in close formation."
-- From the c2 wiki
Eric Y. Kow
> But since I have the ambition to become a real haskeller I was gonna
> make myself acquainted with darcs. Should I skip that and head straight
> for git?
My extremely biased opinion is that you skip git and go straight for darcs ;-)
Why I love darcs
================
Git is a fine revision control system; I like it and I intend to learn more
about it. On the other hand, darcs does some unique, which makes it similar
to Haskell (vs. other programming languages) in way, that one often has a
hard time explaining to folks what it is that makes it so special (the good
news is that the Haskell community is getting better and better at this! and
hope that the same will happen for darcs).
So let's give this a shot. Why darcs? In my opinion, the number one killer
feature of darcs is that it knows how to merge changes without doing *any*
guessing. It doesn't say "well, I have this patch that's supposed to tweak
line number 4, but oops, I think I see that the line must have moved down to
line number 7 because it looks sort of similar". Instead darcs knows with
100% certainty where the right place to apply your patch is. This is because
it uses the full history of patches where everything goes. There is a lot of
talk about a theory of patches, and this is largely what it's about in the
darcs world, finding a precise way to talk about patches. See why some
Haskellers love it? 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.
We love this kind of precision not just because we're theory-fans, but because
it delivers the goods. Being able to apply and unapply patches precisely means
that we can merge changes all we want -- we know that darcs will always
preserve user intent -- plus we can adopt all sorts of new behaviours like
cherry-picking incoming patches ("I'll take patch A, C and E; but not B and D
please; oh, you tell me I can't have E without D? Very well, then") or
cherry-picking changes that you want to undo ("Oops, I actually didn't mean to
write that thing in line 58 and 98, but I still want to keep that thing in line
68, so I'll darcs revert them"... or "Oops, actually I've shouldn't have pulled
in change C, but I still want to keep changes D E, so I'll just say 'darcs
obliterate -p C' to get rid of it"). These kinds of operations happen seamlessly
in darcs. There is no fuss, there is no worry; everything you can do in darcs,
you can un-do. Anything you un-do in darcs, you can re-do.
Darcs past, present and future
==============================
So darcs has a clean theory which makes it possible to use a revision control
system in a new seamless way. Why isn't everybody using it?
Conflicts: It used to be the case that darcs had theoretical problems dealing
with large conflicts (representing a conflict would take exponential space
depending on the patches involved). It took the darcs community many years to
address, but we eventually did, by releasing darcs 2. Darcs 2 repositories add
enough information to the representation of conflicts which allows us to avoid
the exponential blow-up most of the time. For the most part, the problem is
solved. There are still cases where this blow-up can happen (we call them
"conflict fights"), but they are well understood and can be avoided. In the
meantime, we have some folks in the community who are doing some long-term work
refining the darcs theory yet again.
Performance: In addition to the conflicts problem, darcs has suffered from a
lack of optimisation. (In fact, many users may have complained about patch
theory problems, when they may really have been suffering more from performance
issues or a mixture of the two). We have had and still have some practical
day-to-day performance issues. For example, some of my larger repositories
suffer when I use them on an NFS share. Rather than things being
instantaneous, they would take a few seconds and I would get annoyed. Or
perhaps, darcs would make too many connections over a network to fetch a lot of
little files instead of sending them over in one pack. Now that darcs 2 is
out, we have been focusing the bulk of our energy on tackling these basic
performance problems. For other Haskellers in the room, I should point out
that hacking darcs performance would be a great way for you to hone your skills
and to give back to the community. No patch theory needed! Anyway, I wouldn't
be too worried about performance issues. Darcs performs just fine for small to
medium sized repositories. The darcs darcs repository has over 7000 patches
over 6 years with over 160 contributors, no sweat.
Windows: darcs support for Windows used to be a bit uneven. There were a few
details here and there that none of us had time to get to (especially since
none of us were using Windows). Things have gotten quite a lot better since,
and we now have a dedicated Windows Czar who is helping us to bring our Windows
support completely up to speed.
GUIs: This too is changing, although it may take a while. Most of us are quite
happy to use the command line interface to darcs, but we would love to see what
kind of graphical interfaces folks will come out with in the future. In the
meantime, we have recently exposed the darcs Haskell modules a sort of darcs
library, which we hope will be useful to folks working on third party tools.
Note that TortoiseDarcs has recently had a new release supporting darcs 2
Hosting: Aside from the haskell.org services, there was no hosting for darcs,
commercial or otherwise. Now we have patch-tag.com which provides free hosting
for open source projects and paid commercial hosting for private projects.
So putting all this together: Darcs does precision merging, which allows you
to do cool practical things like seamless merging and cherry picking (these
make *my* life easier anyway). There used to be conflicts issues, but they are
mostly solved. There are performance problems, but they only affect large
repositories and they are getting better. There was poor Windows support, this
has improved lots and has a dedicated czar. There is TortoiseDarcs if you're
interested in a GUI. Hosting is available on haskell.org and patch-tag.com.
Darcs and Haskell?
==================
As a final note, darcs as a hacking project would be a good project to
get interested in as a Haskeller. It's very much a real world program,
so there are plenty of things to learn from it and plenty of things to
teach it. We need lots of help. For example, we could use an army of
Haskellers to scrub out our 2003 code and help us hunt down those pesky
performance bugs.
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.
The future is bright. Come join us!
Cheers,
Eric
P.S. Darcs will be hosting its second hacking sprint in Utrecht this
17-19 April as part of the Haskell Hackathon. It'll be a great
chance to meet some darcs hackers and fix some easy bugs :-)
P.P.S. All darcs patches require an inverse. Can a git user please
write an inverse of this email so that Günther can make a
more informed choice?
--
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
Trent W. Buck
> +1. For the most part this was a great email. It probably belongs
> immortalized on the darcs blog and elsewhere.
It could even go in the manual!
I think the first two chapters of the manual should be
1. Why Darcs?
2. Quick Start
...and the stuff about compiling darcs and migrating from other VCSs
moved either to the end (as appendices) or simply onto the wiki.
Maurício
> follow up on some things I hadn't quite understood in my so far short
> venture into the haskell world.
>
> Means: Prepare for a number of naive posts to follow.
We (most of we, actually) have all been there. Some of
us (me, probably) are still there.
> But since I have the ambition to become a real haskeller I was gonna
> make myself acquainted with darcs. Should I skip that and head straight
> for git?
Whatever you choose, you'll take some time to get
used to it. So, if you decided that in the end you'll
use git, but you want to have a taste of darcs first,
I recommend you to read the "Patch theory" of darcs
manual instead:
http://darcs.net/manual/node9.html
There you'll find the best of darcs. If, instead, you
just use darcs for a little amount of time, you'll
only taste the beginner headache.
Best,
Maurício
Iavor Diatchki
Just another point of information, when you make your decision: I
work at a company where we frequently use Haskell and we use git for
almost all of our projects (other VCSs that we use are mercurial and
svn). Also, I use git for all of my open source projects and I find
that it works very well. Darcs is a fine VCS (although I've had
problems with it in the past) but you should not feel that you have to
choose it so that you are considered a "real Haskeller" :-) Good
luck, and welcome to the community!
-Iavor
Eric Kow
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.
Trent W. Buck
> One of the darcs team members, Thorkil Naur, felt that in my enthusiasm I
> was not being sufficiently forthright about darcs's shortcomings.
As for me, I tend to start any review with a list of all the problems I
have with <technology>, on the basis that it's a lot harder to find
informed criticism of a technology than it is to find praise (informed
or otherwise). So I would write an article "Why you shouldn't choose
Darcs", and let readers decide whether the arguments are inadequate.
Henning Thielemann
On Sun, 8 Mar 2009, Trent W. Buck wrote:
> Eric Kow <ko...@darcs.net> writes:
>
>> One of the darcs team members, Thorkil Naur, felt that in my enthusiasm I
>> was not being sufficiently forthright about darcs's shortcomings.
>
> As for me, I tend to start any review with a list of all the problems I
> have with <technology>, on the basis that it's a lot harder to find
> informed criticism of a technology than it is to find praise (informed
> or otherwise). So I would write an article "Why you shouldn't choose
> Darcs", and let readers decide whether the arguments are inadequate.
In general, I also find it more difficult to retrieve well-founded
criticism than to find praise. I like to cite Edsger Dijkstra on this
topic:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD09xx/EWD956.html
"Address to my students"
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html
"How do we tell truths that might hurt?"
Aaron Denney
> Colin Paul Adams wrote:
>
>> Any advantages over Perforce?
>
> I have used Bzr, CVS, Darcs, Git, Hg (Mercurial), Perforce and SVN.
>
> While Perforce is definitely better than CVS (anything is better than
> CVS), Perforce's client workspace concept is a bad idea for complex
> projects (it bit my group of 4 developers time after time).
There are far far more vile version control systems than CVS out there.
I'll say to beware of InterCapped product names, and leave it at that.
--
Aaron Denney
-><-