[PATCH 1 of 6] dirstate: make dirstate.write() callers pass repo object to it

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Oct 15 14:40:41 CDT 2015



On 10/15/2015 08:37 PM, Matt Mackall wrote:
> On Thu, 2015-10-15 at 02:35 +0900, FUJIWARA Katsunori wrote:
>> # HG changeset patch
>> # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
>> # Date 1444843899 -32400
>> #      Thu Oct 15 02:31:39 2015 +0900
>> # Node ID 59a9e52b17e1af3f69b6c9472c9c10a6b00d9b24
>> # Parent  79d86ab65c9def3fdd65ec972bc5fa89688a19ff
>> dirstate: make dirstate.write() callers pass repo object to it
>>
>> Now, 'dirstate.write(repo)' delays writing in-memory changes out, if
>> any transaction is running.
>
> I guess I haven't been paying close enough attention to this as I didn't
> notice the patch that actually introduced this parameter.
>
> We should never pass a repo object to dirstate. It's a layering
> violation that we've carefully avoided for 10 years and makes it way too
> easy to get dirstate.py more entangled with upper levels that it has no
> business knowing about.
>
> Passing a transaction object by itself is ok, as it's a much lower level
> object that dirstate has perfectly good reasons to know about.

replacing
   dirstate.write(repo)
with
   dirstate.write(repo.currenttransaction())

will most probably fit our needs here.

> Similar concerns exist for passing a repo object to a ui, another
> situation we've been carefully avoiding since the beginning of time.
> We definitely do not want ui objects poking at repo objects. They
> probably shouldn't have code specific to pending transactions on general
> principle either.

I'm not sure about what you mean with that last sentence, but the 
dirstate -must- have some collaboration with the transaction. The lack 
of it have been biting us for the past x years.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list