[PATCH 1 of 2 v3] context: stop setting None for modified or added nodes

Augie Fackler raf at durin42.com
Tue Dec 16 19:20:49 CST 2014


On Dec 16, 2014, at 7:32 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:

> 
> 
> On 12/15/2014 11:14 AM, Augie Fackler wrote:
>> # HG changeset patch
>> # User Augie Fackler <augie at google.com>
>> # Date 1418416194 18000
>> #      Fri Dec 12 15:29:54 2014 -0500
>> # Node ID b7772da447df306ddfad854d7acd6b72bb5d5534
>> # Parent  65c854f92d6ba8861414ff3191182fba28777a82
>> context: stop setting None for modified or added nodes
>> 
>> Instead use a modified nullid, so that we can identify modified or
>> added nodes correctly when using manifest.diff().
>> 
>> Thanks to Martin von Zweigbergk for catching that we have to update
>> _buildstatus as well. That part eluded my debugging for some time.
> 
> So, as far as I understand that patch:
> 
> - None was a magic value (in _manifestmatch)
> - None is used by something else for another magic value (in manifest.diff)
> - Having them both equal creates issue, so we change the value of the _manifestmatch
> - The content of the new magic value is absolution arbitrary.

Yup.

> 
> If I got this write:
> 
> - We should improve the documentation around the initialization and usage of this new magic value.

Probably.

> - Using nullid confused me a bit, if you have no specific good semantic to use nullid we should probably use something else. (not sure what our constraint are)

The constraints are “needs to look mostly like a nodeid, but not be a nodeid”. Other parts of the code use 21-byte strings (by +=ing a ‘a’ or ‘m’ or ‘+’ onto the string), so my work on moving the manifest into a C extension already allow for that, which made nullid+something appealing. Does that explain enough?

(I’ll wait on a resend until we talk this bit out.)

> 
> -- 
> Pierre-Yves David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141216/36a606fa/attachment.pgp>


More information about the Mercurial-devel mailing list