[darcs-users] Code internals: reordering patches?

Kevin Smith yarcs at qualitycode.com
Sun Nov 23 18:19:23 UTC 2003

David Roundy wrote:
> This is defined by the "deriving (Eq, Ord)" line (or something like that).
> Because it's derived, it sorts patch types according to the order in which
> they are listed in the constructor declarations, and within types,

Wow. I never would have figured that one out. Thanks!

> The list of patches is already ordered in the order in which they are
> defined.  Every patch has a context, which is a set of patches.  In this
> case the context of each patch in the list includes all the patches coming
> before it in the list.  sortps creates a new list of patches which also has
> this sequential property, that is, in which the context of each patch
> contains all the patches preceding it (and none of the patches following
> it).

 From that paragraph, I still don't understand why you would want to 
sort a list that is already ordered. Hmmm. Let me try to reason it out...

Ok, so you've implicitly described a "natural order" of which patch 
types should be applied before other patch types. if the list is already 
in that order, nothing needs to change. If a patch is "out of order", we 
try to move it in the right direction until it is in order, but if we 
can't that's ok. As you say, it can be a conflict--just a dependency.

So assuming this whole "natural order" thing makes sense, the sortps 
function is pretty clear. But I'm still struggling with the "natural 
order" of patches, which apparently is defined by this order of 

data Patch = NamedP !PatchInfo ![PatchInfo] Patch
            | Move !FileName !FileName
            | DP !FileName !DirPatchType
            | FP !FileName FilePatchType
            | Split [Patch]
            | ComP [Patch]
            | Merger !Bool !String Patch Patch
            | ChangePref !String !String !String

This whole concept still seems odd to me. How much of this sequencing is 
important, and how much is just arbitrary? It seems that we would remove 
directories before removing files below them, for example, which seems 

I guess I'm asking: If you could easily have finer grained control, such 
as allowing two types to be "equal", or splitting directory adds and 
removes into distinct types, would you specify a different ordering?

If you skipped the sortps call, would darcs still work? Or would it 
actually break something?

Thanks again for helping me through this. Hopefully these discussions 
will help anyone who wants to hack on the deep sections of the darcs code.


More information about the darcs-users mailing list