While I'm nominally a fan of darcs (mostly because it was the first
vcs I've seen that is simple when it works, including things like putting
repos on webservers, being able to initialize repos without having to
read the manual, or being able to see changes without being connected
to the reference repo), I keep running into little things like this one:
$ ./darcs-all pull -av
..
$ darcs whatsnew
{
hunk ./packages 8
-libraries/base3-compat packages/base3-compat
darcs
hunk ./packages 45
+
}
So, after bringing my repo up to date, darcs thinks I have local
changes? Fortunately, I've long acquired the habit of recording
darcs-all output, and somewhere burried in that is the following:
$ grep ^Warning mystuff/darcs-all.log
Warning: ./packages-0: renameFile: permission denied (Permission denied)
How can that be a "warning" when it leads to the repo ending
up in a state it shouldn't be in? And why did that problem occur
in the first place? ghc involves many repos, and a script to pull
from all of them, so issueing "warnings" and carrying on as if
nothing had happened does not sound like a good idea at all.
As I said, it is a small thing. But there are lots of those. Enough
to make me wary about darcs keeping my repo safe. Of course,
after you run into such things often enough, you learn to be brave
and try to hack around such issues - after all, it can hardly be worse
than scrapping a big repo, can it? And mostly, that works somehow
and one can continue using the "fixed" repo. But it isn't confidence-
building (#911 is another one that keeps coming up: odd leftover moves/renames linked to get
hangups).
Perhaps all of those small things are fixed if darcs 2 uses darcs 2
repo format, but perhaps not. Just changing formats and rewriting
everything from scratch won't address boring stuff like rename
failures (though a known set of issues might be replaced by an
unknown one).
For all that darcs 2 addressed the biggest issue on the bug tracker,
it actually put me off somewhat because it stopped the steady
progress darcs 1 had been making on all those little issues, and
brought a whole new codebase into the game. Ghc developers
had been able to avoid darcs 1's big issue by avoiding conflicts,
but they can't avoid the continuous attacks by little issues.
Splitting the darcs bug tracker, and re-evaluating every ticket
in terms of darcs 2 might help to reassure darcs 1 users that darcs 2
is not just different, but nowhere worse than darcs 1. But such
re-evaluation would need to be definitive, not maybes like:
"Otherwise, darcs may have some issues with the pending patch.
David keeps fixing pending-related bugs, so it may be something
that was already fixed between 1.1.0pre and 2.0.0, even with the
old format."
Afterwards, resuming the steady progress in stomping on the
remaining little confidence-eroding issues would help. Only then
will the pros of darcs have a chance to shine again, on non-large
repos at least.
Much as I'd have liked to advocate darcs 2 over git for ghc, I
couldn't really have justified that until the little bugs are known to
be fixed. Of course, I doesn't help that darcs is so terribly slow
on ghc (and David indicated that this might be an inherent limitation
of darcs on large projects).
Just another (slightly disillusioned) darcs fan,
Claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
