Re: [Gnu-arch-users] Re: semantics of restricted mkpatch

[Tom Lord]

Another option came to mind.

Let's name things this way (not quite precise but hopefully close
enough):

0) the fundamental theorem of partial changesets

   For all partial-changeset-construction functions `pdelta', the
   changeset application:

        pdelta (ORIG, MOD, LIMITS)[ORIG]

   must be exact (no conflicts, no imprecise patching).


1) minimal partial changeset

   Given a list of files and dirs in MOD, the changeset contains all
   and only only changes to those files and dirs.  A minimal changeset
   can not always be computed which satisfies the fundamental theorem
   of partial changesets -- a useful implementation of this kind of
   partial mkpatch must therefore sometimes refuse to produce a
   changeset.


2) maximal partial changeset

   Given a list of files and dirs in MOD, the changeset contains all
   changes to those files and dirs, all changes (adds, deletes,
   renames) to the names of containing directories, and the smallest
   set of additional changes from the complete changeset to ensure
   that the fundamental theorem of partial changesets holds.

   (Clearly, a maximal partial changeset always exists.  Through
   specific (trivial) examples we can see that maximal partial
   changesets are sometimes smaller than the complete changeset.  I
   think it's a reasonable guess that a maximal partial changeset is
   unique.)


3) upwards closure changeset

   Given a list of files and dirs in MOD, the changeset contains all
   changes to those files and dirs, all changes (adds, deletes,
   renames) to the names of containing directories,  but nothing else.

   This is, modulo the issue of limits matching both ORIG and MOD
   paths, the intention of the algorithm you currently have.

   An upwards closure changeset can not always be constructed that 
   satisfies the fundamental theorem -- again, a mkpatch version that 
   does this must sometimes refuse to produce a changeset.


Let's suppose that we believe that (3) is useful, even if it doesn't
always work -- that it would be preferable to (2).

One hairy solution would be to try to figure out, just from the
indexes, whether or not a given upwards closure changeset is/will be
valid.

A far simpler solution, suggested by Bob long ago if I remember
correctly, is to simply try applying the upwards closure changeset to
find out if it satisfies the fundamental theorem.  (In tla, that would
actually involve not just applying the changeset, but then also
examining the `struct arch_apply_changeset_report' that is returned.
Until we get into hunk-splitting, we can get buy not worrying whether
or not patch(1) is using inexact techniques.)

That's almost a natural fit to the code: we'll need to apply the
changeset anyway to update the pristine copy or to build a new revlib
entry.  It's not yet a perfect fit to the code (e.g. there might not
be a pristine to update) -- but perhaps as the improved caching
mechanisms come on line, this is something to add to the list of
requirements.

A nice side effect of this approach would be that the validity of the
changeset is verified by brute force before doing something like
committing -- it would be great for robustness in the face of hacking
mkpatch.

You mentioned not wanting to wanting to make a complicated LIMITS
language -- which is quite valid -- but I wonder if the long term 
solution doesn't have operators described roughly by:

 {minimal, maximal, upwards} x {mvs/dels/renames-only, all changes ...}

Doing maximal rather than upwards partial changesets is probably
easier in the short term (as a guess) but I could be wrong about that.

-t