
Darcs - Another open source version control system - alagu
http://darcs.net/
======
klodolph
The primary pull of the "patch theory" is that it will allow you to share code
more easily between different "patch sets" (branches / forks). The reality of
software projects means that you can't automate such a process except in the
most trivial cases, and other VCSs handle the trivial cases already.

You can imagine that I write a new filesystem for Linux, but I wait two years
and the FS interface has changed drastically, the old patch is meaningless. If
the patch is sufficiently independent textually, then Darcs lets you reorder
it anywhere you see fit, even if you know that doesn't make sense. You have
detailed knowledge of the system, Darcs doesn't.

By contrast, Git/SVN/Hg folk think about snapshots of development. So it's a
different paradigm.

But the snapshot paradigm is almost always the most useful paradigm, since
every snapshot in history (unless you rebase) is going to be one that was
actually vetted by a real programmer. Reordering patches throws away the
valued _actual snapshots_ that you were working with in favor of automated
reconstructions of what a snapshot _might_ have looked like _if_ you had been
programming in that order.

Of course, you can always do the same dangerous things with Git and rebasing.

~~~
riffraff
What you can't do with git is pull a set of related patches when you have not
created a branch for them. Which is apparently useful, as git has cherry-pick
for that, and rebase.

Except, cherry pick will only work for "in air" commits, and rebase requires
you to review all the commits.

darcs will happily pull a set of related commits knowing the relations between
them. You may have detailed knowledge of the system so in some cases you may
do something better than what darcs does, but that does not mean you should be
resolving merges and commit dependencies by hand all of the time.

Honestly, I have not used darcs in years, but that is the "right" thing I
expect from a VCS, and it has no downsides per se[0].

[0]they may be in darcs implementation, or possibly in the theory, but
definitely not in the feature

~~~
klodolph
Rebase only requires you to review the commits to the same extent that merge
does, unless you're doing an interactive rebase.

Honestly, I expect the differences between Darcs and Git in terms of rebase /
interactive rebase / cherry pick / merge to be a matter of implementation.
Both systems are fed the same input, both track enough of it, so both could
theoretically provide the same output. (I think Darcs is a little better at
it, but every merge should be done with a watchful eye in either system.)

But I get the feeling that the patch-centric model is encouraging users to
play fast and loose with patch order. If you wantonly reorder patches, you
might get a sequence of unusable code bases culminating in the current working
version of your software. It's easy to move a patch that uses a feature to a
point before the feature is introduced.

Basically, the claim that "Darcs automatically groups changes which depend on
each other" is one that I can't take seriously. How can it know which changes
depend on each other, if (for example) they're in different files? By
comparison, I hear from the Git folk advice along the lines of, "Be careful
with rebase, because it is a destructive operation".

And because Git is snapshot-centric, if the app crashes in testing you can
look at the SHA-1 used for the build to check out the exact tree used for the
build, even years later, if necessary. No tagging required.

~~~
Peaker
Git actually doesn't track cherry-picks, at all, and that's been a huge
problem for us.

Consider for example, having two branches: "stable", "master" which have
already diverged. Fixes go into "stable" and are regularly merged into
"master".

Now imagine someone writes a fix F, which must be applied immediately to both
"stable" and "master" and can't wait for the regular merge effort.

So with git, you just cherry-pick F into "stable" and "master".

Now, someone who uses "stable" discovers a big flaw in F, and reverts it. They
assume their work will be merged into "master" as usual.

Then, a merge from "stable" to "master" happens, and the merge sees that the
"stable" branch has 0 changes w.r.t F (commit+revert), whereas it has the F
change in "master". Git's merge algorithm will consider this a trivial case,
and _do the wrong thing_. The merge result will have the broken F application
in "master", and there will be _no conflict_ or any indication of a problem!
This has been a huge problem for us.

So the result of this is that git forces you to either "merge" upstream, or
"cherry-pick", but you really should not mix these two modes.

If you only use "merge", then the guy who merges must intimately understand
everyone's changes in all cases of conflict. If he doesn't, others must help
him resolve the conflicts _on his working directory_. Then, the merge result
is one monolithic commit that makes understanding changes very difficult.

If you only use "cherry-pick", then you lose tracking of which changes have
already been merged upstream, and which haven't. You start relying on the grep
of "git log", which is unreliable, and you have no reliable tools to automate
this. "git cherry" is unreliable and has plenty of false negatives/positives.
Then there are of course problems with patch dependency, where you have to
figure it all out on your own.

In short, the snapshot model is _very_ problematic here. None of these
problems would occur in the darcs model. Unfortunately, darcs does not scale.
Whether that's inherent or not, I don't know. But if it did, I know I'd
definitely prefer to use darcs in a large collaborative effort than git.

~~~
billybob
If I understand you correctly, your problem would occur if, say, you were
maintaining 1.0 and 2.0 branches of a product and needed to apply the same
bugfix to both; you can't merge, so you cherry-pick.

Surely this is something that the Linux project runs into constantly? I wonder
if they have a solution?

~~~
Peaker
In the case of two maintenance branches (1.0, 2.0) you're probably going to
use only cherry-picks, and no merges, and just manually track what you've
already cherry-picked.

In our case, we had the "bleeding edge" branch (master) and a maintenance
branch. Fixes generally go into the maintenance branch and then are merged
upwards. But we allowed "emergency patches" to be cherry-picked upwards (or
downwards) too. The combination is the problem.

If we had stuck to just cherry-picks or just merges, we would not have this
problem. But as I also explained, sticking to one of the approaches has severe
drawbacks too.

------
sirclueless
I like to think of Darcs as the PostgreSQL of distributed version control.
They both have correctness as their first priority, sacrificing a little
performance as necessary. PostgreSQL was very slow at first but it is closing
that gap, and I think the end result is better for it. Git and Mercurial
sacrifice correctness in favor of pragmatism in some cases, by taking
shortcuts such as three-way merges.

Unlike in the relational database world, there is no accepted standard for
interfacing with a versioned repository. It remains to be seen whether Darcs,
like PostgreSQL, will eventually gather enough steam to build a substantial
user base.

~~~
tonfa
I always thought the correctness aspect of Darcs was very weak, from what I
remember most of the original "patch theory" wasn't sound

~~~
sanxiyn
Yes, the original theory was weak and not sound, but they worked on it. There
is some initial work towards Coq formalization.

<http://wiki.darcs.net/Theory>

------
markokocic
Darcs is not "another", it is "the first distributed" version control system
that gained some traction in open source projects. Before git usage exploded,
darcs was almost exclusively used by haskel and lisp libraries.

What killed darcs, besides performance issues with darcs 1, was "one repo one
branch" mode, and tedious way of maintaining long lived forks, which wasn't
that convenient as what git provides.

However, I'm glad that Darcs is still actively developed and used, since it
has very nice theory and model behind it, and it still has some very useful
concept which are quite unique for it.

~~~
decode
> Darcs is not "another", it is "the first distributed" version control system
> that gained some traction in open source projects.

Wasn't BitKeeper in use by the Linux kernel for several years before Darcs
came out?

~~~
loup-vaillant
> "that gained some traction in open source projects."

Therefore, proprietary tools don't count.

------
rdtsc
The Cambrian Explosion of the distributed version control system has passed I
think. Git seems to come out ahead. I think it would be easier to just switch
to it.

I like Bazaar and used Hg, but this is tool used to collaborate with others
(unlike say an editor) so picking a tool that others know and use is important
in a team. Darcs has an interesting approach, sure, but that is not enough for
it to win mind-share, and I wouldn't spend time looking at bit because I will
have a very hard time getting others to do the same.

Also the excitement and euphoria about learning and experimenting with
distributed VCs is passed. I feel, for most they have stopped having the "wow"
factor and became just a tool in the same category as patch, diff, less and
tar.

~~~
tav
It's a sad day, the day a hacker refuses to look at something because they'd
"have a very hard time getting others to do the same". By that same token we
should avoid looking at the likes of Haskell, Erlang, Rust, etc. You are
absolutely right that Git has come out on top, but Darcs definitely merits a
look at least.

For what it's worth, I was in the Monotone [1] camp against Darcs back in the
day... :)

[1] <http://en.wikipedia.org/wiki/Monotone_(software)>

~~~
skrebbel
This. Surely git "has won", but you'd be fitted with a pretty bad sense of
history if you think that this is forever. Thus, it definitely does not hurt
to keep Darcs in view.

I bet that if any version control system is going to replace git, it'll look
at least as much like Darcs as anything else.

I'm no expert by a long shot, but to me it appears that if we're going to try
to _finally_ make version control user-friendly, something inspired by Darcs'
patch algebra may well be at the base of it. While Darcs is impractical for a
whole set of use cases, it's _very_ practical for a whole other set of use
cases.

~~~
qznc
It will be very hard for Darcs (and Bazaar, Monotone, etc.) to get so much
better than git that switching is worth it. Just a better theoretical base for
some edge cases is not enough.

Hg has also quite some mindshare. I consider it the only DVCS, which still
seriously competes with Git. Apart from that, there are niche groups: Haskell
with Darcs, Ubuntu with Bazaar.

~~~
SkyMarshal
Fwiw he didn't say Darcs will replace git, he said that whatever eventually
replaces git will likely implement some of Darcs best features like the patch
algebra.

Hence, it's worth taking a little time to actually understand those features,
even if you never use darcs. Plus the mental exercise and learning something
new is valuable in and of itself.

------
lucisferre
For those interested Linus' comments on Darcs from 2007
<http://markmail.org/message/vk3gf7ap5auxcxnb>

~~~
riffraff
notice that in this message linus says "And in that sense, I do think the two
approaches can _complement_ each other"

And simmetrically, a few years later, david roundy (the original author of
darcs) started working on iolaus[1] which is in fact a darcs-ish
implementation on top of git.

[1] <https://github.com/droundy/iolaus> now abandoned I believe

------
aeontech
I used darcs for all personal repositories for a couple of years. It has a
great UI, but I ended up moving to git for two reasons - a) most projects I
was working on with other people were using git, and b) there was nothing like
github for darcs (and still isn't as far as I know). It was really nice while
it lasted though.

~~~
atechie
Darcs is good for personal use, but I moved away primarily because of the
exponential merge problem. I think darcs2 takes care of it in most of the
cases but NOT always. That is a big question mark for production repository.
Darcs is easy to get started with though - to anybody interested I recommend
this link - <http://blog.interlinked.org/tutorials/darcs.html> .

On the other hand if you want to move from darcs to git , use the following -
<https://github.com/purcell/darcs-to-git>

~~~
kowey
I'll just add that these days, people should consider using the Darcs bridge
instead: <http://wiki.darcs.net/DarcsBridgeUsage>

It's not ready for bi-directional incremental bridging, but for one shot
conversions, it should be just fine.

The Darcs bridge uses the Darcs library to do things and understands Darcs
better.

------
cdaven
"Another" could imply that Darcs is new, but it's not. According to Wikipedia,
the first release was in 2003.

We tried using Darcs at work in 2006, but the early exponential merge issues
made it impossible to use. (One time, we let Darcs try to merge "some changes"
over the weekend, but it never completed.) Unfortunately we chose Subversion
instead.

~~~
danssig
Ack, Darcs had a problem so you went with SVN? I hope you've at least switched
to using git as your SVN client by now.

~~~
parfe
Does git-svn now handle svn:externals properly? I can't find anything saying
it now has support. I'd love to switch to git as my client, but we have
upwards of 70 externals for libraries we maintain, and converting those to git
submodules is not an option. Well it is, but it is far more work than simply
using git as a client.

~~~
danssig
I don't know. But when choosing a system I wouldn't chose SVN for
svn:externals. Git has submodules which I find nicer.

~~~
parfe
I don't think Git submodules were added until 2009 (at least that's what the
commit history looks like). We deployed with SVN at least six years ago, long
before git could compete.

Still, I would like to use git as my svn client, but it's just not a suitable
replacement without externals handled nicely.

------
kowey
Hi all! As a Darcs developer (mostly cheerleader), I'd like to make a general
comment that Darcs should be seen more as a version control system we're
trying to build than one you should use right away. Please keep an eye on it
if you're interested in the idea, but don't encourage your boss to use it just
yet :-)

It's made a lot of progress over the years, and works great for my needs, but
we do still have serious bugs and performance problems we need to sort
through; and yes still lacks a lot of critical tooling/infrastructure around
it.

We love what we do, and think that we have something new to bring to the table
(among other things, making it easy to pinpoint commits that you want to pull,
delete, etc; DVCS'es may all do some cherry picking ala git add -p, but Darcs
makes it possible to use it everywhere), but it may take us a _very_ long time
to get to stage where we can responsibly talk about it.

There lot's of work to do, lots. If you're looking into getting to some
Haskell hacking, consider Darcs as a good side project to get into. We can use
you.

~~~
smichael
I'm a Darcs user and occasional contributor. I have been using it continuously
on small-medium projects to my great benefit since at least 2004. Now we have
just released 2.8, the developer community has been growing, and sure Darcs
has its problems but so does every VCS. We also have unique strengths. Is it
really necessary to still be saying "we're not ready" and "don't use it yet" ?

I would like to see hard data and experience reports of where Darcs worked and
didn't work for people, instead (so I'm loving this thread.) Here are a couple
of repos I've worked with:

\- hledger: 2477 patches, 251 files, 66M, 5 years of activity

\- Zwiki 0.x: 1897 patches, 295 files, 12M, 5 years

\- Darcs: 10171 patches, 731 files, 51M, 10 years

\- GHC before it moved: 23413 patches, 1353 files, 162M, 5 years (+ 10 years
of converted history)

Here's the darcsstat script that reports these numbers:
<https://gist.github.com/2653180>

------
etherealG
A quote from the darcs wiki:

This is why darcs currently doesn’t always works so well for keeping a “local
branch” of some source. The local deviations are likely to cause exponential
conflicts after time. Local deviations must either be isolated in some way
(kept in separate files) so they never conflict, or changes from upstream
needs to be merged in “by hand” and recorded as local patches that doesn’t
conflict with the local changes.

Can anyone help me reconcile why I would give darcs a try over git if I can't
do local branching?

~~~
loup-vaillant
My guess would be, because you don't need to.

First, you can do "local branching" by cloning your repository. On a local
filesystem, `darcs get` is fast (uses hard links). And instead of `darcs
branch`, you use `cd` (personally, I don't see how `cd` is worse, do you have
some pointers about that?).

Second, the Darcs way of managing patches gets you "spontaneous branches".
<http://wiki.darcs.net/SpontaneousBranches> The main advantage lies in that
you can select the patches you push to other repositories. Say you work on
some feature. Suddenly you need to fix a bug. The way to do it is, fix the bug
right away then send the relevant patches (easy if you name your patches
sensibly). Your unfinished feature simply won't get send (unless of course
there's an actual conflict).

~~~
etherealG
I see your point about local branching, but I do prefer git's approach for
simplification on large branch sets. Some of the git repos I work with have
upwards of 200 branches, having those in folders to be manually managed would
be a little overwhelming.

------
CountSessine
I had the pleasure of using Darcs in an open source project some time ago. Can
a long-time Darcs user explain to me what I was doing wrong?

The build for the project had passed on most platforms, but on one platform in
particular (the one I was interested in), the build agent started failing on a
particular day a month before. Being able to determine which commit a build
started failing at has a great deal of real engineering value, but I couldn't
figure out a way to do that with Darcs. The patches are ordered in the
repository according to Darcs' own preference, and they're dated according to
when they were committed locally, not when they were pushed.

I discussed this point with someone else and they said, to paraphrase,
"usually, I know which of my patches has caused a problem, so this is a non-
issue." It wasn't a non-issue in this case, of course, because _I_ didn't know
which of his patches had caused the issue, and no one else had cared to figure
out why this third-tier platform wasn't building.

Is there any way at all to characterize what exactly a build machine is
building at a particular time with Darcs? With perforce and subversion,
there's a commit number. Git has a commit SHA hash. What can you do in a build
agent to log exactly what is and isn't being built with Darcs?

~~~
kowey
Hi! I'm sorry this isn't any easier yet. In Darcs, one approximation of this
sort of thing is to take the whole history (sequence of patches) and hash
that. Unfortunately, this approach fails to recognise different darcs-allowed
patch orders as having the same history. It's fine as a conservative default,
but we'd like something better. See [short secure
ID](<http://wiki.darcs.net/Ideas/ShortSecureId>) for some thinking about the
problem.

------
jgfoot
Perhaps darcs' most prominent user base is the guys who work on GHC, the
Glasgow Haskell Compiler. They still use it, but have not been completely
happy: <http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation>

~~~
Chirono
Actually, GHC has been using GIT for about a year now. There was a lot of
discussion but darcs has (mostly) been dropped. There are a few libraries that
are still darcs-controlled but generally because nobody has got round to
migrating them I think...

------
haakon
How does darcs compare to git these days? I know it used to have some
significant performance issues on large repos.

~~~
kowey
It still does.

We've made a lot of progress. You'll see people saying that their performance
problems have gone away. But we have a long way to go.

Two things to fix: downloading repos is slow (latency, too many small files);
and conflict merging can be slow under a few cases. The first one we have a
fix for from a summer of code project, but needs more work. The second issue
is a very deep, very serious, and will take us a seriously long time to think
through.

------
papsosouid
It is weird that all the comments are about patch theory. I use darcs because
it is by far the easiest, simplest to use DVCS. I don't know anything about
patch theory, and I don't care about it at all. I just know I can have a DVCS
noob using darcs effectively in a couple minutes, and it will merge properly.

------
DannoHung
Darcs is pretty nifty, but until the atomic patch theory has been verified,
I'm happy to stay with git.

~~~
dons
Are you expecting git to be verified soon too?

~~~
etherealG
git's only "theory" that could potentially be verified is merge resolution.
which has been.

I think darcs approach is a little different.

~~~
dons
git has plenty of properties that are supposed to be true. The developers
write tests for them. The properties being tested could be proven instead.

