[darcs-users] darcs conflicts/dependencies -- is patch theory the place to start?

Stephen J. Turnbull stephen at xemacs.org
Fri Sep 21 16:05:48 UTC 2012


AntC writes:

 > Thanks Stepehen. You're possibly not reading this in context of my "very 
 > speculative approach"
 >  http://lists.osuosl.org/pipermail/darcs-users/2012-September/026698.html

I suppose so.  My context is based on experience that if you want a
useful product, whether a program or a theory, you need to take the
user's point of view.  Patch theory uses intuitive criteria (in *both*
senses of "informal/imprecise" and "makes sense") like "same effect"
that don't have precise definitions.

IMHO would help if we defined what patch theory is trying to do
*first*, rather than seeing what we can prove from random axioms and
then tweaking the definitions until they fit the theorems.  The
problem is that the tweaked definitions tend to be more precise but
make less sense.  YMMV, of course, but that's where I'm coming from.

 > Conceptually, this is trying to achieve the same thing as L/S/L's
 > approach for a line-id, but piggy-backing on darcs' current
 > approach for precisely observing hunk changes. (From what you're
 > saying, it would be even better to piggy-back on git's ability to
 > spot hunk moves.

No, I'm not saying that.  For Darcs, whose fundamental concept is
patch commutation, we want a concept of "patch target position" that
is not tied to the content on a line because commutation may be
possible despite changes in line content.  But git only knows about
content, and doesn't perform commutes.

My point in mentioning git is simply that git makes it pretty clear
that a practical VCS doesn't need to distinguish between container and
content.  At least, AFAICS (but YMMV).

 > important than tracking the container. But in complex code bases
 > (with programs and scripting and install routines, etc in a variety
 > of languages) there are semantic connections between content in
 > different files and connections for file dirs/names to/from content.

Yes, project content refers to tags ("file names") attached to the
organizing structure ("files") of the project.  But AFAICS, this
doesn't have much to do with the container/content distinction.

 > Given that there are typically many lines in a repo with exactly
 > the same content (blanks, a single opening brace or single closing
 > brace, single open comment or single closing comment, horizontal
 > line separators between sections, standard program initiation
 > sequences/shutdown sequences/error handlers/template calls), how
 > can [git] be so sure?

Because the unit of comparison is the file, and the "alphabet" is
lines.  If two files "before" and "after" when compared by diff turn
out to have X% of the same lines in the same order, then "after" is
considered to be a rename of "before".  Similarly for copies.

 > Suppose the programmer moves some text, then edits it before
 > recording?

Those are different lines, and git won't consider it a move, but a
delete and an insert.

The idea in git is not to track individual lines.  It's to track
sequences of lines.  Tracking individual lines requires using the
pickaxe, which doesn't perform very well, and gives fuzzy answers (ie,
sets of lines that might be matches).

 > With move-file we expect the programmer to instruct darcs, so that
 > it can both record the patch and make the move.

It's not merely inconvenient, it is known to require training effort
in bzr.  Maybe it's worth it (the bazaar developers certainly think
so), but Darcs users expect a relatively high usability.

 > > Theoretically, yes.  But will users properly discriminate between
 > > those commands?
 > 
 > Don't worry, the VCS is going to validate that the move-lines does
 > exactly capture the change in content.

I'm not worried about the content.  The intent is what I'm worried about.

 > But is that any worse than darcs or git?

That's not the standard I use.  My question is, if after all our
effort, we end up with users who don't use the features, was the
effort worth it?



More information about the darcs-users mailing list