[PATCH 2 of 4] merge: use file context objects instead of acting directly on localrepo

[Sean Farley]

Pierre-Yves David writes:

> On 08/20/2014 01:16 PM, Sean Farley wrote:
>>
>> Pierre-Yves David writes:
>>
>>> On 08/20/2014 12:56 PM, Sean Farley wrote:
>>>>
>>>> Pierre-Yves David writes:
>>>>
>>>>> So, reply to patch 1 failed to be sent so you got reply to patch 2
>>>>> without reply to patch one, lacking some useful context.
>>>>
>>>> Ah, yeah, that did help :-)
>>>>
>>>>> On 08/18/2014 11:08 PM, Sean Farley wrote:
>>>>>>
>>>>>> Pierre-Yves David writes:
>>>>>>
>>>>>>> On 08/18/2014 07:42 PM, Sean Farley wrote:
>>>>>>>> # HG changeset patch
>>>>>>>> # User Sean Farley <sean.michael.farley at gmail.com>
>>>>>>>> # Date 1406339242 18000
>>>>>>>> #      Fri Jul 25 20:47:22 2014 -0500
>>>>>>>> # Node ID d1a21cc0bc4ba5764a1f8760fd041a91939b4d00
>>>>>>>> # Parent  594d00e49cea6cd2ebb92c0570e7502f8797e232
>>>>>>>> merge: use file context objects instead of acting directly on localrepo
>>>>>>>
>>>>>>> Can you remind me what is the motivation behind have those methods
>>>>>>> (write/removes) on the filectx instead of the changectx itself?
>>>>>>
>>>>>> Merge (and friends) need a way to change the data for a filectx.
>>>>>> Currently, this is done by actually writing merged data onto disk, then
>>>>>> having localrepo.commit read that off of disk.
>>>>>
>>>>> Why does it especially needs to be from a filectx? Why can't it be from
>>>>> a changectx?
>>>>
>>>> Because filectxs hold the data of the file.
>>>>
>>>>>> If we want to do a merge in memory, then we need a way to change this
>>>>>> data in a filectx. That's why the previous patch needs to cache the
>>>>>> filectx in __getitem__ (so that the changed data is not thrown away).
>>>>>
>>>>> I know we need a was to store the data. but why can't this be done in
>>>>> changectx?
>>>>
>>>> Because filectxs hold the data of the file.
>>>
>>> Let me rephrase:
>>>
>>> Why do you insist for having the filectxs holding the data?
>>>
>>> The changectx could be holding the data too. What is the argument to get
>>> put them on the filectxs ?
>>
>> This is the way filectx and context is designed. It makes the most
>> sense.
>
> So, data are stored in filelog. And filectx is just a nice overlay to 
> access it. The filelog is not storing the data itself.
>
>> If you're going to put file data into contexts, then why not just
>> put it all into localrepo? You could also have a convenient way to
>> access it:
>>
>> repo.getdata(ctx, filename)
>
> We are talking about setting additional, in memory data here. They need 
> to be stored somewhere and having them in the memctx would solve the 
> cycle probleme (as the memctx need access to this data and cannot 
> reference filectx).

I didn't understand why you were so concerned about object cycles until
I read about garbage collection. I'll rework this series to store the
data in memctx and access it through memfilectx.

> (Finding the appropriate name for the fallacy you just perpetrated is 
> left as an exercise for the reader)

It was supposed to be a joke about adding new methods to localrepo :-P