Goals

[Tom Lord]

   Goal: design a patch format that

      a) is compatible with the standard `patch' program in the sense
         that `patch' will not choke on it, and will apply as much of it
         as it can.

I would make that a "desirable" goal, not a "constraining" goal.

      b) expresses tree changes (directories and files
         added, copied, renamed, and removed)

And there's a need to deal with "inexact" patching regarding those
(i.e. the tree to which a path is applied has different structure from
the ORIG tree used to generate the patch).

      c) supports generic metadata.  What I have in mind are Subversion's
         "properties", but there may be other sorts of metadata used by
         Arch or other systems; none of it should be lost.

A design principle of arch is that "meta-data" is part of the source
tree.  Thus, the patch mechanism in arch is unaware of a distinction
between data and meta-data.  When arch needs to add meta-data, it
takes the changeset format as a design constraint.

   That's all.  If these goals seem wildly off-base, this would be a good
   time to say so :-).

Not wildly.  Just slightly.

And slightly misfocused.   

Let's talk tree reararrangements.  They imply the ability to recognize
a logical identity of a file that is not tied to its physical location
in the tree.   I think the "logical identity" problem is a separable
subproblem of the general changeset challenge.

So: how do we assign logical identities to files?   

Towards a _straw man_ proposal, I'll point to some tutorial docs about
arch's approach:

  http://regexps.srparish.net/tutorial/inventories.html

  http://regexps.srparish.net/tutorial/inventory-tags.html


When we want to talk about how that relates to changesets, this may be 
relevant:


  http://www.fifthvision.net/open/bin/view/Arch/PatchSetFormalSemantics



-t