(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 <step...@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.
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
