Every other automatic dependency in darcs's patch theory is strictly a 
syntactic requirement -- for example a patch that inserts a hunk into a 
file syntactically depends on the patch that creates the file.

But the automatic dependency of a hunk patch on the hunk patch that 
touched the *preceding* or *succeeding* line is not a mere syntactic 
requirement -- it is a heuristic in which darcs guesses that such 
patches might be semantically dependent.  This guess could be right or 
wrong depending on what language and what engineering practices are used 
in the file.

My co-worker at Allmydata just started adding dummy lines in between 
each element of a set so that patches that change elements of the set 
will not automatically depend on the most recent patch which changed the 
adjacent element.

I suggest that darcs should stick to its simple rules about syntactic 
dependency and leave the semantics to the user.

Regards,

Zooko

I think this is more complicated than it seems. Patches must
have the same result independently of which order they are
applied in. Adjacent patches that don't remove any lines could
be applied in any order -- they would commute without conflicts,
just changing each other's line numbers. So to prevent that from
happening, they are made to depend on each other. (At least I
think this is something like what happens.)

But I've been thinking about this for some months now and come
up with a crazy idea. If patches could be marked as "dark
matter" (perhaps a stupid name) things could work out. The idea
is that dark patches would only exist in the inventory and patch
store, but they would be invisible in the working and pristine
trees, and also be invisible in all output from darcs, e.g.,
'darcs changes'. Pulling the later of two adjacent patches, but
not the former, would commute them by making the former patch
dark (and pull it, but invisibly). Pulling the "real" former
patch would commute it with its dark twin, that disappears, and
with the later patch to get things in the right order. The idea
is that the dark patches should "stand in" during patch
reordering and conflicts / mergers, so that things are kept
consistent, and they can be converted to their "material form"
later.

But I really don't know enough about the patch guts yet to
understand if this is at all possible to do. It might also make
things unnecessarily complex.

But anyhow, what's "missing" is a way for darcs to tell the
order of these adjacent patches (other than making them depend
on each other).

Tommy's right here.  So far as I know, darcs never introduces a dependency when
it isn't required for consistency.  Patches to adjacent lines only depend on
each other if one or the other of them is an addition or removal (i.e. has only
'+' lines or only '-' lines).  This is necessary because these patches change
line numbers in a way that could lead to trouble under the wrong circumstances
of merging (i.e. the wrong sequence could lead to the modified line turning up
on the wrong side of the added line.

David

This is interesting.  So if I understand correctly a patch like this:

[second patch!
a**20070801225146] {
hunk ./f 2
+Whee I am the second line of a file!
}

Does not need to *depend* on a patch like this:

[1st patch!
a**20070801225131] {
addfile ./f
hunk ./f 1
+Whee I am the first line of a file!
}

Because it would be syntactically clean for patch two in the absence of patch
one to result in a file which has only one line which says "Whee I am the second
line of a file!".

But then how would darcs know if patch one were later added that the line
therein should go *before* this line instead of after?  So currently darcs
solves the problem of knowing the order by making patch two depend upon patch
one, but this is perhaps an unnecessarily heavy-handed way to preserve that
information.

Am I right?

On Wed, Aug 01, 2007 at 10:55:08PM -0000, Zooko wrote:
> This is interesting.  So if I understand correctly a patch like this:
> 
> [second patch!
> a**20070801225146] {
> hunk ./f 2
> +Whee I am the second line of a file!
> }
> 
> Does not need to *depend* on a patch like this:
> 
> [1st patch!
> a**20070801225131] {
> addfile ./f
> hunk ./f 1
> +Whee I am the first line of a file!
> }
> 
> Because it would be syntactically clean for patch two in the absence of patch
> one to result in a file which has only one line which says "Whee I am the second
> line of a file!".

I'm not sure in what sense you are using the word "syntactically."  Do you
mean to say that this would be syntactically clean but semantically
unclean?

> But then how would darcs know if patch one were later added that the line
> therein should go *before* this line instead of after?  So currently darcs
> solves the problem of knowing the order by making patch two depend upon patch
> one, but this is perhaps an unnecessarily heavy-handed way to preserve that
> information.
> 
> Am I right?

No, it's not unnecessarily heavy-handed, it's necessarily heavy-handed.
That's not quite true, we could encode extra meta-data which would record
the location of the second patch's data using some form other than line
numbers (one possibility is explored in the paper "A Principled Approach to
Version Control", but I don't know if it's published online).  Darcs uses
the simple approach of using line numbers to describe which part of the
file is being modified, and I don't think this is likely to change soon.

In any case, eliminating this dependency would require creating a new patch
type that uses a new scheme (presumably including explicit references to
other patches by name) to describe what portion of the file is to be
modified.
-- 
David Roundy
Department of Physics
Oregon State University

On Aug 1, 2007, at 5:08 PM, David Roundy wrote:

> On Wed, Aug 01, 2007 at 10:55:08PM -0000, Zooko wrote:
>> Because it would be syntactically clean for patch two in the  
>> absence of patch
>> one to result in a file which has only one line which says "Whee I  
>> am the second
>> line of a file!".
>
> I'm not sure in what sense you are using the word "syntactically."   
> Do you
> mean to say that this would be syntactically clean but semantically
> unclean?

I meant that it would be consistent and it would in some way "make  
sense" from a perspective which was ignorant of the meaning of the text.

>> But then how would darcs know if patch one were later added that  
>> the line
>> therein should go *before* this line instead of after?  So  
>> currently darcs
>> solves the problem of knowing the order by making patch two depend  
>> upon patch
>> one, but this is perhaps an unnecessarily heavy-handed way to  
>> preserve that
>> information.
>
> No, it's not unnecessarily heavy-handed, it's necessarily heavy- 
> handed.
> That's not quite true, we could encode extra meta-data which would  
> record
> the location of the second patch's data using some form other than  
> line
> numbers (one possibility is explored in the paper "A Principled  
> Approach to
> Version Control", but I don't know if it's published online).   
> Darcs uses
> the simple approach of using line numbers to describe which part of  
> the
> file is being modified, and I don't think this is likely to change  
> soon.
>
> In any case, eliminating this dependency would require creating a  
> new patch
> type that uses a new scheme (presumably including explicit  
> references to
> other patches by name) to describe what portion of the file is to be
> modified.

Please help me understand this better.  Currently darcs makes patch  
two depend upon patch one if patch two added or removed a line which  
was adjacent to a line that was last touched by patch one.

This is not so much because we want to prevent the contents of patch  
two from being present without the contents of patch one, but rather  
because if we didn't have that dependency then we wouldn't be sure  
*where* to place the contents of patch two versus the contents of  
patch one in the case that both patches were present.

Is this right so far?

Thanks!

Regards,

Zooko

On Thu, Aug 02, 2007 at 10:46:10AM -0600, zooko wrote:
> On Aug 1, 2007, at 5:08 PM, David Roundy wrote:
> >>But then how would darcs know if patch one were later added that the
> >>line therein should go *before* this line instead of after?  So
> >>currently darcs solves the problem of knowing the order by making patch
> >>two depend upon patch one, but this is perhaps an unnecessarily
> >>heavy-handed way to preserve that information.
> >
> >No, it's not unnecessarily heavy-handed, it's necessarily heavy- handed.
> >That's not quite true, we could encode extra meta-data which would
> >record the location of the second patch's data using some form other
> >than line numbers (one possibility is explored in the paper "A
> >Principled Approach to Version Control", but I don't know if it's
> >published online).  Darcs uses the simple approach of using line numbers
> >to describe which part of the file is being modified, and I don't think
> >this is likely to change soon.
> >
> >In any case, eliminating this dependency would require creating a new
> >patch type that uses a new scheme (presumably including explicit
> >references to other patches by name) to describe what portion of the
> >file is to be modified.
> 
> Please help me understand this better.  Currently darcs makes patch  
> two depend upon patch one if patch two added or removed a line which  
> was adjacent to a line that was last touched by patch one.
> 
> This is not so much because we want to prevent the contents of patch  
> two from being present without the contents of patch one, but rather  
> because if we didn't have that dependency then we wouldn't be sure  
> *where* to place the contents of patch two versus the contents of  
> patch one in the case that both patches were present.
> 
> Is this right so far?

Right.  We don't store any "hidden" information, so in order to ensure
consistency, we need to make sure that reordering the two patches is
reversible.  If it isn't reversible (as is the case in this example), then
the two patches can't be reordered, which means that one depends on the
other.

> Thanks!

You're welcome!
-- 
David Roundy
Department of Physics
Oregon State University