[darcs-users] Fwd: Darcs Problems

[John Lato]

(I didn't mean to go off-list, sorry for the break in context)

On Fri, Mar 8, 2013 at 8:17 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Did you intend to reply to list?  Feel free to forward my reply, if so.


> John Lato writes:
>
>  > > I don't understand what "C (deps B1)" means.  Remember that in a
>  > > forced commute B1 has the same effect as -A.  Normally dependencies
>  > > are based on effects.  In Darcs (at least as of the last revision of
>  > > the wikibook), the dependency on B and/or B1 seems to go through the
>  > > conflictor D that represents/contains it and the information about how
>  > > it conflicts with A.
>  >
>  > It means that C depends on the effects of B1, and thus transitively on
> the
>  > effect of A also.  I believe that this would be represented as a
> conflictor
>  > that would refer to both B and A, however I don't think that's relevant
>  > here.
>
> Maybe not.  But for me, on the one side your specification is too
> incomplete to formally argue that this makes sense -- you need a lot
> of implicit assumptions about the semantics of your constructs.  On
> the other, that conflicter seems like a necessary aspect of the
> implementation.  Nor is it spurious, the conflictor remains in the
> repo AFAIK.
>
>  > I don't understand what you're saying.  If darcs pulls from a
> repository,
>  > the repository it's pulling from must have all the dependencies for its
> own
>  > patches.  So if the user tries to pull something that isn't trivial (in
> the
>  > sense under discussion), it can offer to pull the patches that would be
>  > missing.  If the user doesn't do this, they'll certainly have to fix it
>  > manually.
>
> My point is that as currently implemented, Darcs has no way to
> understand semantic dependencies.  If your patch depends on the .c
> file but is textually unrelated to the .h, Darcs won't offer the .h.
> It's easy to imagine much less transparent dependencies (calls to new
> functions implemented in new files not touched by the relevant
> patches).  I think after just one such experience users would decide
> that darcs pull --ask-about-pulling-transitive-dependencies is just
> too unreliable to ever use.  (Hopefully they won't generalize that to
> Darcs itself! :-/ )
>

Really?  I thought you endorsed the approach of pulling patches without
getting their dependencies when somebody else suggested it.  Apologies, I
must have gotten some wires crossed.

In any case, it seems there's growing desire for a feature to get some
patch(es) without pulling all their dependencies, as others have expressed
on several occasions.  I think any approach (even if it's diff+patch+commit
new patch) will have to deal with these issues.  I'm simply trying to come
up with a way that's more principled than that.

I don't see any hope that Darcs will be reimplemented to handle such
> semantic dependencies "properly" any time soon.  Sure, you could do it
> straightforwardly with LLVM-based C (or C++), I guess, but not many
> language implementations provide the necessary analytical tools.


Right, and then there are README's, LICENSE, and other natural-language
files.  I don't expect to see this implemented soon!


>  > > Your contexts are way underspecified.  In fact, what you are thinking
>  > > about is a *partial* function {contexts}->{contexts}, and in
>  > > particular patch C is a (total) function C:{b, b', ...}->{contexts}
>  > > where {b, b', ...} are the contexts where you are allowed to apply C.
>  > > So you want to construct an appropriate B' and b', but in many cases
>  > > it's a very bad idea to throw away all the information in patch B:a->b
>  > > (the sum of "whatever's necessary to get to 'b'").
>  >
>  >
>  > This of course is the other feature that I would like, and I agree this
>  > part is dangerous.  But it's likely no more dangerous than
>  > git-rebase.
>
> But it is!  (At least, AFAICS.)  Remember, every git commit points to
> a *complete* tree (in the sense of containing a version of everything
> added to that point).  That's not true of Darcs commits, even
> including transitive dependencies (except for tags).  This is part of
> what's in the back of my mind when I suggested using a tag for a base
> patch (which suggestion was incorrect).  But maybe if the user tags
> appropriately, the most recent tag will pull in the necessary stuff
> most of the time, so the base patch can be dependency-free.
>

Every git commit points to a complete tree in that sense, but that doesn't
mean
that everything in "some-branch" will exist in "some-rebased-branch".  After
all, that's what git-rebase is for: changing history!  It's entirely
possible
to lose commits (and dependencies) by rebasing.  If you have

A - B - C

where B adds Foo.hs, and C adds "import Foo" to Bar.hs (which already
existed in A), then git rebase --onto A B thisBranch

will give you

A - C'

without any notification that anything is wrong (i.e. all commits would
apply cleanly).

In C', Bar.hs still has "import Foo", but "Foo.hs" no longer exists;
it's exactly the same problem.

In darcs, it may be wise to add C as a dependency of D, but now it's
entirely impossible for users to get C without also getting B.  Darcs is a
less powerful tool than git; why else would the recommended way of handling
certain cases be "don't use darcs, use diff+patch"?  But if darcs supported
a pull-without-dependencies, then at least if you have the same series of
commits and manually-specified dependencies darcs could warn you that it
won't work and will require manual fixup.  That's better than git can do.

You think users will find this unreliable.  I think users will quickly
adapt to it, and moreover I suspect that any users who expect the power
available in git would find darcs crippled.

 > In the end, it would be up to the user to make sure that everything
>  > is recorded properly, and in particular to code up a suitable
>  > replacement for the not-present patch(es) B.  If the user decides
>  > in the end it would be easier to get all the dependencies too,
>  > that's their own decision.
>
> Yes.  I believe that even you will quickly come to the conclusion that
> it's not worth it: just clone the repo and be safe.
>

You mean darcs clone ~/repoA ~/repoC; diff -c -r ~/repoA ~/repoB | patch -d
-p1 ~/repoC (or something like that), then fix up repoC and, assuming repoB
has a number of small, atomic commits re-record them all again?
 Manually re-specifying all the commit logs and manual deps?  And then have
to merge them again later?  No thanks, I can just use git-rebase.  I've
used darcs for longer than git, and I like darcs' patch model better than
git's DAG, but I also like tools that can stay out of my way when
necessary.  And there's almost nothing as frustrating as a tool that simply
will not allow you to perform a necessary operation.

As a tool, Darcs has a small userbase and even in the Haskell community its
impact is small and shrinking.  Its only real purpose at this point is
a research project for patch theory.  But if patch theory can't offer a
solution to this problem, which occurs in practice and is satisfactorily
solved by git, then darcs' demise (already appearing to be inevitable) will
simply happen much more quickly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20130308/911a3ee1/attachment.html>