"Variance Adjusted Patching", Context, and File Identities

[Tom Lord]

      	Misha Dorman:

	It appears that there are three main applications for changesets:

	a) [...] fuzzypatch(NEW,delta(ORIG,MOD)) ("general inexact
	   patching")

	b) [...] exactpatch(ORIG,delta(ORIG,MOD))=MOD ("exact patching")

	c) [...] applying mergepatch(delta(ORIG,MOD),delta(ORIG,NEW))
           to NEW ("variance adjusted patching")


(I think your mergepatch notation isn't quite right but I'll talk
about that in a later message about v.a.p. -- briefly, there are
_four_ trees involved in v.a.p., not three.)

	Note that (c) is not necessary, since the general case (a) can
	be used instead in most cases.

Yes but v.a.p. gives an interestingly different result and a variation
on v.a.p. (v.v.a.p.?) can be more interesting still.

	Note also that fuzzypatch from (a) can be factored to make use of mergepatch 
	from (c):
	      fuzzypatch(NEW,delta(ORIG,MOD)) = 
	        mergepatch(derivepatch(NEW,delta(ORIG,MOD),delta(ORIG,MOD))

Again: your notation is misleading you.  v.a.p. (mergepatch) takes
four trees, not three.  fuzzypatch always takes three.  I don't think
there's any natural way to define fuzzypatch in terms of mergepatch,
but later on I'll talk about defining mergepatch in terms of
fuzzypatch_prime and some other tools.

Hmm.  Actually, you could probably make a mergepatch5 that takes
_five_ trees, and define both mergepatch4 and fuzzypatch in terms of
that -- but I don't immediately see any practical benefit to that.
It would raise the question of "inexact variance adjustment".

	(c) [v.a.p.] does not require context 

It makes good use of context lines.

	or file identities (as has been explained, it 
	can use the history provided by the SCM tool).

Our goals here include not relying on any revision control tool.



	Q: what is the relative importance of these three scenarios?

I'm willing to say that they are all equally important because I don't
see any obstacle at all to supporting all three in the changeset
format.

	Q: how much context is appropriate to protect against
	   automatically applying conflicting patches?

	Q: how much context is appropriate to accurately locate
	   changeset hunks? 


As you note, there's no perfect answer -- just a lot of accumulated
experience with defaults.


	Final thought: I haven't thought through the impacts of the
	"keep conflicts in the tree" aka "support conflict-resolution
	patches" aka "lets share the work of resolving these 100-odd
	conflicts" idea. Is it safe to just park that idea for a
	while? Or do we need to analyse it up front?

I'm not sure -- having not solved that problem yet (or spent much time
on it).   My intuition is that we can work out first how to compute a
changeset, then abstractly how to apply it, then start worrying about
representing conflicts "in the tree", and then go back and make any
necessary changes to how changesets are computed and applied to deal
with conflicts stored in the tree.

-t