[darcs-devel] [patch1971] introduce some generic merge function helpers

[Ben Franksen]

Ben Franksen <ben.franksen at online.de> added the comment:

>> So, should we sort the conflicting Nons in a V2 conflictor when we write
>> them to disk (or for simplicity whenever we show them)?
> 
> Is this actually necessary?

I don't think so. But it would avoid running into the same problem again.

> What I really had in mind with my TODO
> comment was just to take a closer look at the new output, check it's
> still correct and then update the test.

This wold be fine, too, modulo above comment. BTW, making the format
canonical, we will also mean a one-time re-generation of the test
bundles, see my patch.

>> What ordering
>> should we use? Prim.V1 comes with a suitable ordering but FileUUID does
>> not. However, I guess testing FileUUID with RepoPatchV2 is sort of
>> wasted anyway, so we should simply drop the unit tests for that combination.
> 
> Agreed.
> 
>> Even of we do that, we need to decide how to treat the context patches
>> in a Non. I am inclined to be practical here and just compare the prims
>> at the end. This is not perfect as theoretically we could have equal
>> prims with different contexts (i.e. duplicate prims), except that I
>> believe in this case RepoPatchV2 would have created a Duplicate, so this
>> should be safe.
> 
> Two patches could be completely different while in the same context, but
> identical textually in different contexts. e.g.
> 
> 1: addfile foo/X
> 2: addfile bar/X
> 
> in context:
> 1: [] ; addfile foo/X
> 2: [mv foo old ; mv bar foo] ; addfile foo/X
> 
> Maybe that's not possible for Non as the context has to not commute with
> the prim, but I'm not too convinced by the general statement.

Right. I did not take into account that the prims at the end are not
comparable due to different contexts.

> Why not just sort including the contexts?

Because that is more difficult ;-) It means we have to write a
comparison function for RepoPatchV2. Doable, but I am not too keen.
Another option could be to take the effect of the context and use that
for sorting. This is much easier, but I am not 100% sure it will avoid
all edge cases.

> If this is just about having a
> canonical ordering we don't really care what it is, but having any
> possibility of equality would mean there'll be edge cases.

True.

>> patch 0e80c5c65e9706de477cf6cdd2beefac0a0e7655
>> Author: Ben Franksen <ben.franksen at online.de>
>> Date:   Sat Feb 22 12:59:41 CET 2020
>>   * sort Nons when showing a RepoPatchV2
> 
> You remove the tests for RepoPatchV2 FileUUID in this patch without
> explanation, might be better in a separate patch.

Agreed.

> PrimOrd would benefit from a bit more description of when it's
> appropriate to use it.

I think we should reject the patch and just regenerate the test bundles.
The fact that the V2 conflictor format is not canonical is just one more
infelicity of a format with lots of other problems, most of them more
severe. Not worth the effort.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1971>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 4211 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-devel/attachments/20200226/d38bae3d/attachment-0001.key>