[PATCH 2 of 5] localrepo: invoke dirstate.unsureifambig in wwrite for safety

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Jun 30 22:51:50 CDT 2015



On 06/30/2015 08:52 AM, FUJIWARA Katsunori wrote:
> At Mon, 29 Jun 2015 01:55:56 -0700,
> Pierre-Yves David wrote:
>>
>> On 06/28/2015 09:23 PM, Martin von Zweigbergk wrote:
>>>
>>>
>>> On Sun, Jun 28, 2015 at 9:07 AM FUJIWARA Katsunori
>>> <foozy at lares.dti.ne.jp <mailto:foozy at lares.dti.ne.jp>> wrote:
>>>
>>>
>>>      OK, I'll try to fix problems by invoking `dirstate.write()` at (*1) !
>>>
>>>
>>> Great! I wasn't sure if I was missing something and wasting everyone's
>>> time. I'm glad it now seems it was worthwhile. And thanks for working on
>>> this! I'm pretty sure I've been bitten at least twice by this while
>>> rebasing (dirty file appeared clean).
>>>
>>> Just a reminder that adding a check for dirty dirstate in
>>> localrepo.wwrite() seems like a good way to find the places to fix (and
>>> perhaps for printing a warning after we've fixed the known buggy callers).
>>>
>>> Does it make sense for workingctx._dirstatestatus() to do the writing?
>>> Or maybe it needs to be done at a higher level that's aware of any
>>> running transaction?
>>
>>
>> This discussion start to get long and complexe let's says it is time to
>> create a Plan page on the wiki. The idea is to have a single place where
>> to look for the latest state of the project, the various step we have to
>> do and that are the progress made on it.
>>
>> I've create a stub here:
>>
>>     https://mercurial.selenic.com/wiki/DirstateTransactionPlan
>>
>> (Thanks again for documenting and tackling these issue)
>
> Thanks for your many suggestions and starting wiki page up, too !
>
> I'll fill the page at first (maybe, with some additional topics around
> consistency for dirstate/transaction)

Do not fell obligated to perfectly fill the page before sending patch. 
There is a couple of things that seems obviously the right things to do 
and were we could move forward with.

The intend of the page is not to drown you under a bureaucratic burden, 
more to keep track of the current issues and solutions. The goal is (1) 
to ensure someone can know what's going on without going throught 20 
emails and (2) someone can resume the work if you get distracted in the 
middle of it.

Copy pasting large chunk of the email thread should be good enough.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list