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
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
From: Martin Langhoff <hidden> Date: 2016-06-15 22:43:18
On 6/25/07, Linus Torvalds [off-list ref] 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
From: Jan Hudec <hidden> Date: 2016-06-15 22:43:18
On Mon, Jun 25, 2007 at 08:45:57 +1200, Martin Langhoff wrote:
On 6/25/07, Linus Torvalds [off-list ref] wrote:
quoted
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 [off-list ref]
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
From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:18
"Martin Langhoff" [off-list ref] writes:
quoted
"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.
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
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
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.... ;)