Darcs

Darcs

[Bu Bacoo]

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

Re: Darcs

[Linus Torvalds]

On Sun, 24 Jun 2007, Bu Bacoo wrote:
> 
> 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 ....).

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

Re: Darcs

[Martin Langhoff]

On 6/25/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Ahh, a chance to flame! I will never back down from such a challenge!
>
> Darcs is .. umm .. ehh..
>
> "Academic".

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

Re: Darcs

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]

On Mon, Jun 25, 2007 at 08:45:57 +1200, Martin Langhoff wrote:
> On 6/25/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >Ahh, a chance to flame! I will never back down from such a challenge!
> >
> >Darcs is .. umm .. ehh..
> >
> >"Academic".

> 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.

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.)

> 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.

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.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Darcs

[Theodore Tso]

On Mon, Jun 25, 2007 at 08:45:57AM +1200, Martin Langhoff 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. 

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

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

Re: Darcs

[Junio C Hamano]

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

>> "Academic".
>
> 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.

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.

Re: Darcs

[Dan Chokola]

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:
>  "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> >> "Academic".
> >
> > 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.
>
> 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.

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

Re: Darcs

[Linus Torvalds]

On Sun, 24 Jun 2007, Dan Chokola wrote:
> 
> 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."

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

Re: Darcs

[Dan Chokola]

On 6/24/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sun, 24 Jun 2007, Dan Chokola wrote:
> >
> > 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."
>
> 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.
>

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.

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

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

Re: Darcs

[Martin Langhoff]

On 6/25/07, Dan Chokola <dan@chokola.com> wrote:
> 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.

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

Re: Darcs

[Linus Torvalds]

On Mon, 25 Jun 2007, Martin Langhoff wrote:
> 
> The darcs commandset (init, push, pull) is what git, hg and bzr have
> today in common.

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

Re: Darcs

[Josh Triplett]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

Linus Torvalds wrote:
> On Sun, 24 Jun 2007, Bu Bacoo wrote:
>> 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 ....).
> 
> Ahh, a chance to flame! I will never back down from such a challenge!
> 
> Darcs is .. umm .. ehh..

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

- Josh Triplett



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: Darcs

[Johannes Schindelin]

Hi,

On Wed, 27 Jun 2007, Josh Triplett wrote:

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

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

Ciao,
Dscho

Re: Darcs

[Bu Bacoo]

On 6/28/07, Josh Triplett <josh@freedesktop.org> wrote:
> Linus Torvalds wrote:
> > On Sun, 24 Jun 2007, Bu Bacoo wrote:
> >> 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 ....).
> >
> > Ahh, a chance to flame! I will never back down from such a challenge!
> >
> > Darcs is .. umm .. ehh..
>
> Wow.  You completely skipped the opportunity to flame Visual Source Safe (vss)
> users. :) Too easy?
>
> - Josh Triplett
>
>
>
>

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

Re: Darcs

[Florian Weimer]

* Bu Bacoo:

> What do you think about darcs?

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.

Re: Darcs

[Bu Bacoo]

Florian, what are you moving to? To GIT?

On 6/25/07, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Bu Bacoo:
>
> > What do you think about darcs?
>
> 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.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>