[PATCH 2 of 5] localrepo: invoke dirstate.unsureifambig in wwrite for safety
FUJIWARA Katsunori
foozy at lares.dti.ne.jp
Tue Jun 30 10:49:52 CDT 2015
At Mon, 29 Jun 2015 04:23:47 +0000,
Martin von Zweigbergk wrote:
>
> [1 <text/plain; UTF-8 (7bit)>]
> On Sun, Jun 28, 2015 at 9:07 AM FUJIWARA Katsunori <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).
Thanks for your many suggestions, too !
> 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).
You mean steps like below, or others ?
- `localrepo.wwrite()` tells dirstate that the file is "updated"
- dirstate clears "updated" mark of files, on which `normal`,
`normallookup` and so on are applied
- `dirstate.write()` warns (with `ui.develwarn`) if there are files
still marked as "updated"
BTW, as Pierre-Yves pointed out before, `merge.update` may invoke
`localrepo.wwrite` on forked worker processes, and marking in
`localrepo.wwrite` doesn't work well in such case :-<
> 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?
I'm putting `dirstate.write()` into `workingctx._checklookup()` at
first, because occasional test failure for "unexpected status"
prevents any subsequent development :-)
Then, explicit `dirstate.write()` invocations will be replaced by
another one if needed, while making in-memory dirstate changes visible
to external process.
----------------------------------------------------------------------
[FUJIWARA Katsunori] foozy at lares.dti.ne.jp
More information about the Mercurial-devel
mailing list