[RFC] Multi-parent diffs

[John Arbash Meinel]

Aaron Bentley wrote:
> Matthew D. Fuller wrote:
>> On Fri, Apr 06, 2007 at 02:31:03PM -0400 I heard the voice of
>> Aaron Bentley, and lo! it spake thus:
>>> I've drafted a spec for a new diff representation that I think we
>>> should consider adopting:
>> Peripherally related:
> 
>> It would be useful to be able to store diffs against a revision that's
>> not one of the parents
> 
> Yes.  In theory, it doesn't matter whether the parents are really parent
> revisions, for the purposes of the diff.
> 
>  (maybe even one that isn't in the ancestry).
>> For one thing, this can lead to smaller diffs (in the extreme case,
>> when you're just restoring the content of an old revision, your diff
>> can become empty).
> 
> The problem is then: how to you handle the fact that the annotations are
> different?
> 
> Aaron

I think we need to discuss annotations in general, though. As I think it
would be reasonable to split annotations out into a separate file/cache,
rather than storing them inline. I'm still happy that we generate them
as we go, rather than after the fact. But most of the time when
extracting contents, you just care about the contents, not the
annotations. So having them mixed means you have to do extra processing
to ignore the extra information.

Which would also let us doing fancier things with how we store the
delta, since it would be decoupled from the line-based annotation store.
 Some things like making "human understandable" annotations, versus
"optimally small" deltas, etc.

I realize you have been thinking of other things for "line identity"
which may effect this more, so it isn't something that I'm strictly
advocating. As we need to evaluate the alternatives.

I will agree with Robert, though. That it complicates the search if you
can have deltas against non-ancestors. (Also because we currently copy
the deltas across directly).

I think 'hg' gets away with this because they don't have shared
repositories which can mix 10 different projects in the same files.
00changelog.i would get pretty messy if you commit your plugins next to
your bzr data like I do. Not to mention that when you "hg pull" my
plugin, you would have to grab all of bzr at the same time...

John
=:->