Robin:
>> Let us suppose we replace the patch-log directory with
>> three files. [....]
Tom:
> It's a very promising idea in general terms (ignoring inessential
> details of what you are describing). It would need more thought about
> what exactly goes into the summary files you are describing, how they
> will be managed to avoid lossage, how they interact with changeset
> computation and application, and how that will impact various forms of
> query. Plus the things on top of those that I'm forgetting right now.
I should add to that, this:
One nice thing about the way patch-logs currently work is that mkpatch
and dopatch don't have to know anything (much) special about them.
Merging creates (perhaps redundently) new files; reverting removes
(perhaps redundently) old files.
It's not impossible to get conflicts in the patch log but it's pretty
hard and the easiest way I know of to do it is a bug and will go away.
So, summary files instead of patch-log is an interesting idea -- but
one question is whether it hairs-up mkpatch/dopatch or whether the
format can be designed in such a way that the nice properties of the
current system can be preserved.
(Now that you mention it -- I think a similar idea _did_ come up a
long time ago but the mkpatch/dopatch hair was the stumbling block.
One thing that has changed since then is that I might now be more
willing to consider a little mkpatch/dopatch hair than I was then.)