Darcs

Hello guys (girls?)

What do you think about darcs?

There was a lot written/spoken about morons and stupidos around thinking in cvs / svn, etc... (what would be the words for dudes around vss ....).

But not a lot of darcs, even if there are tools like Darcs-Git, etc... Are git and darcs supposed to extend each other? Or? The patch algebra in Darcs looks to me pretty similar to Linuse's patch-SCM used for kernel bellow 2.6.12.something?

Thanks for opinions.

Bu

On Sun, 24 Jun 2007, Bu Bacoo wrote:

Ahh, a chance to flame! I will never back down from such a challenge!

Darcs is .. umm .. ehh..

"Academic".

Ok, I realize that's a pretty weak flame, and I'm sorry. It's not that darcs users are "stupid" or "complete morons" or "donkey turds with arms and legs", it's just that the whole project is centered around some academic ideas that have absolutely no relevance in real life, and that just don't work in practice.

In other words, it's a fun project, but it's largely irrelevant. The whole underpinning of darcs ("everything is a collection of patches" and the "patch algebra") is kind of interesting, but it's irrelevant. The thing it solves is not the thing you want solved, and you really don't want to handle conflicts at a "patch" level.

I personally think darcs is closer to a smart "quilt" than a "final" SCM. It's good for keeping track of patches, but let's face it, if you have really big changes, you don't want to handle them the way darcs does.

And in that sense, I do think the two approaches can _complement_ each other. A lot of people use quilt (or quite often, something similar, based on a SCM in the background: git has and stgit and guilt, hg has "mercurial queues"). And it's absolutely true that you want to have a "fluid" level too, and darcs can do that.

But you do *not* want to do the whole project history that way. At some point, you need something that works at another level than patch queues. Darcs itself kind of has something like this with "checkpointing", but the fact is, git is just better at this.

So it basically boils down to the fact that I don't think darcs solves the real problems, and won't scale up. It's versioning model seems *totally* broken, for example.

Fundmantal example: somebody has a problem/bug. Tell me how to tell a developer what his exact version is - without creating new tags, and without having to synchronize the archives. Just tell the developer what version he is at.

In git, you just give a revision number. In darcs, what the *hell* do you do? And that's a pretty damn fundamental operation for a source control management setup! As far as I know, darcs only has patch identities.

			Linus

On 6/25/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

OTOH, and from the POV of someone closely following the SCM tools in the last few years (and using almost all of them), darcs was the first usable DSCM in the camp. I am not sure how much of its commandline user interface was borrowed from BK or elsewhere, but darcs was _easy_, where Arch was extremely hard to use.

The darcs commandset (init, push, pull) is what git, hg and bzr have today in common. At least _I_ learned about how it could be easy by watching people use Darcs (and feeling very ashamed of my baroque Arch usage). The focus on patch tracking (as opposed to "snapshot" tracking) and the whole patch algebra are two misfires I'd say. Snapshot-tracking DSCMs are winning (faster and fundamentally more reliable), and the patch algebra doesn't quite scale and (as far as I've heard) sometimes ends in unsolvable corner cases.

And the closer we get to Darcs UI the happier I feel ;-)

cheers,

martin

On Mon, Jun 25, 2007 at 08:45:57 +1200, Martin Langhoff wrote:

Arch is not in fact distributed. One key feature that makes things distributed is that object (revision in SCM) identity is independent of their location (repository in SCM). And in Arch that is not true.

Revisions independent of repositories (and branches) is what makes the ad-hoc branching, that makes git (and hg, bazaar and darcs) so easy, possible. Arch claimed to have easy branching, but it was still the old explicit model.

(Besides yes, I can confirm that Arch was not the easiest thing to use.)

IMHO the patch algebra also falls short of it's goal. The idea is supposed to be that you can cherry-pick easily. However, in practice many changes that are easy to cherry-pick are textually dependent in something like import list, list of files in makefile or such. While git cherry-pick will happily apply such patch and give you a single easy to resolve conflict, darcs will just insist on pulling the other patch as well.

On Mon, Jun 25, 2007 at 08:45:57AM +1200, Martin Langhoff wrote:

Darcs was first announced in April 2003 [1].

Linus first started using BK to manage the Linux source tree in 2002; I first started using Bitkeeper to manage e2fsprogs back in 2001; and BK was first available in late 1998.

So to give credit where credit is due, the whole "$foo init", "$foo commit", "$foo push", "$foo pull" DSCM UI was first pioneered by Larry McVoy and BitKeeper, not Darcs.

						- Ted

[1]  http://www.haskell.org/pipermail/haskell-cafe/2003-April/004139.html

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

I second this. Before I started contributing to git in its early weeks, I staged my own changes to my day-job project in darcs to trickle them in to the company's central repository (I was sufficiently faster than other members of the project and I had to pace myself).

It would have been much more difficult for me to grasp the basic concepts of how "distributed development" process works, if I did not have an exposure to Darcs before I started, especially because I never used BK.

On Mon, 25 Jun 2007, Martin Langhoff wrote:

I really think the credit goes to BK, not darcs. 

BK is why a lot of git commands look like they do: I didn't want to re-implement BK, but I definitely wanted to reimplement the flow. At least for common stuff.

The fact that darcs may have been more usable than other open source scm's says more about the other open source scm's than it says about darcs.

arch/tla in particular was (is?) horribly messy. I tried to look at it before starting git, but even just a cursory look convinced me to look away..

		Linus

Linus Torvalds wrote:

Wow. You completely skipped the opportunity to flame Visual Source Safe (vss) users. :) Too easy?

- Josh Triplett

Hi,

On Wed, 27 Jun 2007, Josh Triplett wrote:

It's no fun if the targets of your ridicule don't even get it.

Ciao, Dscho

On 6/28/07, Josh Triplett <josh@freedesktop.org> wrote:

We've been talking about version control systems, not version killers.... ;)

* Bu Bacoo:

The UI is nice, but darcs is quite slow (even if you don't hit the exponentional corner case in the merge algorithm).

My main gripe with darcs, and the prime reason why I'm moving away from it, is its lack of support for software archaeology. If you haven't tagged a tree at some point, you'll face lots of trouble when you try to restore something that resembles the tree you had back then. This is a direct consequence of the "heap of patches" approach, but it's a real nuisance, and the benefits of the increased flexibility don't make up for it, IMHO.

Florian, what are you moving to? To GIT?

On 6/25/07, Florian Weimer <fw@deneb.enyo.de> wrote:

Resent to the mailing list because my crappy mail client defaulted to
HTML. Sorry.
---------- Forwarded message ----------
From: Dan Chokola <dan@chokola.com>
Date: Jun 24, 2007 7:38 PM
Subject: Re: Darcs
To: Junio C Hamano <gitster@pobox.com>
Cc: Martin Langhoff <martin.langhoff@gmail.com>, Linus Torvalds
<torvalds@linux-foundation.org>, Bu Bacoo <bubacoo@gmail.com>,
git@vger.kernel.org

On 6/24/07, Junio C Hamano <gitster@pobox.com> wrote:

This is an interesting thread. My own background with Git is that it's the first SCM I've ever used. And it comes from XMMS2 being the first open-source project I ever contributed back to. I joined shortly after the kernel (and XMMS2 team, likewise) had switched from BitKeeper to Git. So, as Linus said in his tech talk, "My brain didn't rot from years of thinking CVS was doing something sane," and now I can't imagine ever using a centralized SCM.

The interesting thing is that now I'm learning about all the other distributed SCMs (most of which came before Git) now, after having learned Git, so my experience is backwards from a lot of you. When I first started, had I known about something like darcs, I probably would have loved it much more than git, which was only usable to the highest-level minds at first. I had to use cogito for almost everything. But now it's as easy to use as its distributed friends and so I don't think ease of use is much of an issue for anyone anymore.

What I have noticed is a lot of nitpicking, of which I'm guilty, too. The issue Linus brought up about Darcs and versioning is not one I typically see surface in real life. Users usually complain about some _release_ version or, "I updated last week." The maintainer's reply is almost always, "Between (release x.x.x|last week) and now we fixed that problem, check out the latest source." While it could certainly get annoying when trying to track down a very specific version, it's not a make-or-break issue that's going to cause anyone to drop Darcs and flock to Git.

I also saw another developer become upset about using Git over Mercurial partly because of the lack of documentation on things like the pack formats. And my own nitpick is that I would never use Mercurial because it's slow and in Python (a language I despise). The truth is there's a huge feature overlap between Git an Mecurial (as well as Darcs and others) and the fundamental stuff remains constant. In fact, I managed to clone, update, and diff some changes with mercurial without ever reading any documentation.

Just thought I'd throw my observations in the ring instead of lurking on the list. We'll see if any of it is relevant. :)

-Daniel "Puzzles" Chokola

On Sun, 24 Jun 2007, Dan Chokola wrote:

Actually, in the kernel, we are getting quite a lot out of "git bisect", and people throw git SHA1's around to describe where they are, or a particular commit.

Which never happened with BK.

So I think that the _ability_ to name revisions easily across different uses is quite important, because it then drives behaviour.

Without it, you'll never notice you need it. With it, you start wondering how others handle it.

For example, we have people like Andrew, who don't really "use" git, and he starts pointing to commits with their git ID, because he sees them flying past, and he knows they are stable and useful for things like gitweb.

			Linus

On 6/24/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

I wholeheartedly agree it's important as far as the big picture of SCM is concerned. Though I will say that the kernel development is an extreme case, where there's a huge number of developers and incredibly fast development where matching features are needed from the SCM. And I love how Git is born out of this extreme case, as it leads to a lot of great features that often scale down, too. But some of them matter less to, say, a small, well-integrated team of 5 or 10 people. And an idealistic model like the one offered by Darcs might even work better there since corner cases don't show up often.

I'm spoiled by Git and the fact that it has these great abilities and features that set it apart, and I'd love everyone to use it. But I'd like people to know that many attributes of Git and other DSCMs don't differ all that much. (Please don't call me ugly and stupid. ;) And actually, this is something of a selling point, because it makes it Git seem cozy and familiar.

So, relating back to the original post, and extending on Linus' 'academic' analogy, Darcs is like a thesis project from university that proves how DSCM can be done scientifically. Git is grown-up Darcs that proves how DSCM can be done practically. The bottom line is the foundations of DSCM, cheap branching, easy merging, and the like, can be done very similarly in either Darcs or Git, so moving from one to the other leaves you with a largely familiar set of commands.

Git really does have a way of spoiling its users (I don't know how CVS/SVN users live), no argument here.

-Daniel "Puzzles" Chokola

On 6/25/07, Dan Chokola <dan@chokola.com> wrote:

I don't think it's like that. More like

 - BK showed it's done
 - Darcs picked some good bits from BK (while no other foss dscm did
until git/hg/bzr came along) but got distracted with interesting but
not-that-useful stuff - see patch algebra.

cheers,

m