[darcs-users] unique features + exponential time issue

[Eric Y. Kow]

Hi all,

Thanks for the spirited discussion!

> > > [1] All the fancy talk about patch theory comes to nought when you get
> > > bogus conflicts, like when *nothing was changed*.

> > This is a FAQ, answered in the manual.  This can be a genuine bug, and
> > since Darcs only has text-manipulation (rather than program semantics
> > manipulation) patches, it can't tell the difference.  David chose the
> > conservative route.

Stephen is right.  This particular case is just a a conservative design
decision, not a bug.  You could say that it is a flaw, in the sense that
many users find it to be horribly counterintuitive.

Good news: darcs 2.0 will some recognise situtations where two patches
make identical changes and not treat them as conflicts.  I think this
applies to primitive patches ('changes').  Unfortunately, overlapping
primitive patches will probably still be treated as conflicts.  So if
hunk patch A modifies lines 3-4 of a file whereas hunk patch B modifies
the lines 2-5, they will conflict even if patch B includes the changes
from patch A.  Nevertheless, the more usual and perplexing case
(patch A and patch B both modify the same lines in the same way) will
not be treated as conflicts.  Please treat this as a rumour until David
confirms.

> > > Or when you inserted code into the same spot as someone else.

This does not trip my bogosity detectors.  Could you clarify how
inserting different text in the same place is anything but a conflict?

> (1) I consider Darcs to suffer from several showstopper bugs, some of
> which I have enumerated.

Yes, but overall, it depends on how big the show is.  The big conflicts
issue, poor handling of partial repositories are the two biggest ones in
my mind right now.

Darcs still works great for smallish repositories on the order of 1000
patches. Checkpoints and tags helps for some practical things.
Unfortunately, darcs has been painful for GHC-sized repositories and is
become problematic even for darcs-sized ones.

I also have a sneaking suspicion that for some users, there are some
banal practical issues that are being mistaken for the conflicts issue,
but this would take some detective work to be sure.  Hurts either way.

> (2) I think there's little interest and/or impetus in solving any of
> them. (I know David Roundy has been putting in some work on the
> conflict misery problem, though -- kudos!)

Oh we *definitely* have interest.

I admit that lately, most of our darcs-hacking momentum consists of
David's work (*).  The good news is that David is putting in *a lot* of
momentum.  I can count some 60+ patches in his personal conflicts tree
that shall eventually make their way into unstable.  Kudos indeed!

(*) +Ganesh for QuickCheck work. 

> (3) I consider Darcs to be nearly dead in terms of major feature
> development right now.

Perhaps a better way of saying this is that darcs is doing a lot of work
under the hood right now.  The most recent major feature (2007-04) is
the new hashed inventory mode, which allows, among other things, for a
new 'lazily partial' repository that avoids some of the problems that
have been plaguing the darcs partial repository feature.  This also
counts as under-the-hood work for darcs-2.0.

I think the informal roadmap consists of:

 * fix patch theory and the exponential time issue

Everything else depends on what users are willing to contribute.  For
example, one user has volunteered to improve our pristine cache (S: no
pressure).  If he succeeds, darcs would become much more robust wrt
Unison, other version control systems, IDEs, stupid sed tricks etc.

Personally, I am working on our handling of filepaths, which involves
some staging work (adding more types into our code) and some thinking
work (how do we want to handle filepaths).  This work will fix a handful
of silly bugs related to not recognising absolute and relative paths
correctly.

This was meant to fit into my recent 'fix easy bugs' campaign, in which
non-patch-theorists roam the bug tracker and squashing the easiests bugs
we can find.  Everyone is invited to join!  It's a great way to
participate even if you're feeling a little brain-dead, as I do lately.

> > > [2] Darcs stalls almost consistently on Darwin/Intel when using
> > > OpenSSH's control master support. This is presumably the reason why
> > > it's off by default now.

Yeah, I gave up on this because I didn't understand it.  Seems to affect
Linux users too on large repositories, but that's just one report.

Are ssh-agent or setting up ControlMaster in your .ssh/config not
satisfactory workarounds?  I'd be especially curious to hear back from
Mac/Intel users who tried the latter option.

> If a seasoned Haskell developer can't fix the issue, then I'm not even
> going to consider thinking about possibly trying.

I'm only 'seasoned' in the most basic sense of 'learned Haskell in
2003 and used it since'.

This bug is probably one of those silly things which becomes blindingly
obvious when revealed.  It could benefit either from a more
knowledgeable or experienced developer than me, or an outsider with
fresh insights.  You may not claim to be in the first category, but I
think you at least fall into the second :-)

-- 
Eric Kow                     http://www.loria.fr/~kow
PGP Key ID: 08AC04F9         Merci de corriger mon français.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20071021/7fcf5fdf/attachment.pgp