Re: Darcs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

On 6/24/07, Junio C Hamano <gitster@xxxxxxxxx> wrote:
 "Martin Langhoff" <martin.langhoff@xxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux