<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 1, 2015 at 11:07 AM FUJIWARA Katsunori <<a href="mailto:foozy@lares.dti.ne.jp">foozy@lares.dti.ne.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At Mon, 01 Jun 2015 17:02:10 +0000,<br>
Martin von Zweigbergk wrote:<br>
><br>
> [1  <text/plain; UTF-8 (7bit)>]<br>
> Thanks. I think I knew most of that, but the subrepo case for interrupted<br>
> update was a good example I had not thought about. My question remains,<br>
> however. In the sequence in this test case, you do this:<br>
><br>
> $ hg update -q -C 3<br>
> $ touch -t 200001010000 b<br>
> $ hg status -A b<br>
> $ hg --config extensions.abort=$TESTTMP/abort.py merge 5<br>
> $ touch -t 200001010000 b<br>
><br>
> What I'm wondering is what real-world scenarios could lead to file b's<br>
> timestamp being the same in those two cases (where you artificially touch<br>
> them here). Since we said that 'hg status' is run strictly after (at<br>
> whatever granularity is recorded by the FS, perhaps second-level), how can<br>
> the 'hg merge' produce a timestamp for file b that's the same as what 'hg<br>
> update' does?<br>
<br>
`hg merge` can be aborted by same reason at `hg update` before<br>
updating dirstate:<br>
<br>
  (0) cleanup working directory for examination of `hg merge`<br>
      (let's ignore this while focusing on examination of `hg merge`)<br>
> $ hg update -q -C 3<br>
<br>
  (1) ensure forcibly that `repo.dirstate['b']` has valid timestamp<br>
> $ touch -t 200001010000 b<br>
> $ hg status -A b<br></blockquote><div><br></div><div>We said that this 'hg status' is run at 200001010000(00)+1sec (otherwise the timestamp in the dirstate would be unset). Correct?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  (2) execute `hg merge`, but it is aborted before "update dirstate"<br>
      for example:<br>
      - invalid updating in subrepositories<br>
      - keyboard interruption by user, file I/O error and so on<br>
> $ hg --config extensions.abort=$TESTTMP/abort.py merge 5<br>
<br>
  (3) (re-)set timestamp of 'b' on the filesystem for mis-leading<br>
      this emulates that `hg merge` update 'b' before 200001010000(00)+1sec<br>
> $ touch -t 200001010000 b<br></blockquote><div><br></div><div>Since 'hg status' above was run at 200001010000(00)+1sec (or later), how can this (interrupted) merge be run at 200001010000(00)?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
In addition to it, '.hgsubstate' may have to be focused on.<br>
<br>
Regardless of `hg update`/`hg merge` result, size of it on the<br>
filesystem is often kept, because '.hgsubstate' consists of "hashid<br>
subrepopath": "hashid" of hg subrepo is always 40 letters :-)<br>
<br>
<br>
(Do I understand your question correctly ?)<br>
<br>
<br>
> On Sun, May 31, 2015 at 10:24 PM FUJIWARA Katsunori <<a href="mailto:foozy@lares.dti.ne.jp" target="_blank">foozy@lares.dti.ne.jp</a>><br>
> wrote:<br>
><br>
> > At Fri, 29 May 2015 18:05:18 +0000,<br>
> > Martin von Zweigbergk wrote:<br>
> > ><br>
> > > [1  <text/plain; UTF-8 (7bit)>]<br>
> > > On Wed, May 27, 2015 at 10:06 AM FUJIWARA Katsunori <<br>
> > <a href="mailto:foozy@lares.dti.ne.jp" target="_blank">foozy@lares.dti.ne.jp</a>><br>
> > > wrote:<br>
> > ><br>
> > > > # HG changeset patch<br>
> > > > # User FUJIWARA Katsunori <<a href="mailto:foozy@lares.dti.ne.jp" target="_blank">foozy@lares.dti.ne.jp</a>><br>
> > > > # Date 1432745859 -32400<br>
> > > > #      Thu May 28 01:57:39 2015 +0900<br>
> > > > # Node ID b82f32b8734b109b84f533dc62dd3f23195d1e0a<br>
> > > > # Parent  ab9f120295b59933d1acd72771f01b5fac8d221d<br>
> > > > localrepo: invoke dirstate.unsureifambig in wwrite for safety<br>
> > > ><br>
> > > > Modified file may be mis-recognized as clean by dirstate, if mode,<br>
> > > > size and timestamp of it on the filesystem aren't changed.<br>
> > > ><br>
> > > > To avoid such ambiguous situation, this patch invokes<br>
> > > > `dirstate.unsureifambig()` at the end of `localrepository.wwrite()`.<br>
> > > ><br>
> > > > When file is cleanly reverted or updated, subsequent<br>
> > > > `dirstate.lookup()` makes `dirstate.unsureifambig()` a little<br>
> > > > redundant. But it is enough cheap for keeping consistency.<br>
> > > ><br>
> > > > diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py<br>
> > > > --- a/mercurial/localrepo.py<br>
> > > > +++ b/mercurial/localrepo.py<br>
> > > > @@ -927,7 +927,9 @@<br>
> > > >              self.wvfs.write(filename, data)<br>
> > > >              if 'x' in flags:<br>
> > > >                  self.wvfs.setflags(filename, False, True)<br>
> > > > -        return len(data)<br>
> > > > +        wsize = len(data)<br>
> > > > +        self.dirstate.unsureifambig(filename, wsize)<br>
> > > > +        return wsize<br>
> > > ><br>
> > > >      def wwritedata(self, filename, data):<br>
> > > >          return self._filter(self._decodefilterpats, filename, data)<br>
> > > > diff --git a/tests/test-merge1.t b/tests/test-merge1.t<br>
> > > > --- a/tests/test-merge1.t<br>
> > > > +++ b/tests/test-merge1.t<br>
> > > > @@ -206,4 +206,60 @@<br>
> > > >    $ hg revert -r -2 b<br>
> > > >    $ hg up -q -- -2<br>
> > > ><br>
> > > > +Test for ambiguity from same size, timestamp and mode<br>
> > > > +<br>
> > > > +  $ cat > $TESTTMP/abort.py <<EOF<br>
> > > > +  > from mercurial import extensions, merge, util<br>
> > > > +  > def applyupdates(orig, *args, **kwargs):<br>
> > > > +  >     orig(*args, **kwargs)<br>
> > > > +  >     # emulate aborting before "recordupdates()"<br>
> > > > +  >     # => files are changed without updating dirstate<br>
> > > > +  >     raise util.Abort('intentional aborting')<br>
> > > > +  > def extsetup(ui):<br>
> > > > +  >     extensions.wrapfunction(merge, "applyupdates", applyupdates)<br>
> > > > +  > EOF<br>
> > > > +<br>
> > > > +(file gotten from other revision)<br>
> > > > +<br>
> > > > +  $ hg update -q -C 2<br>
> > > > +  $ echo 'THIS IS FILE B5' > b<br>
> > > > +  $ hg commit -m 'commit #5'<br>
> > > > +<br>
> > > > +  $ hg update -q -C 3<br>
> > > > +  $ touch -t 200001010000 b<br>
> > > > +  $ hg status -A b<br>
> > > > +  C b<br>
> > > > +  $ cat b<br>
> > > > +  This is file b1<br>
> > > > +<br>
> > > > +  $ hg --config extensions.abort=$TESTTMP/abort.py merge 5<br>
> > > > +  abort: intentional aborting<br>
> > > > +  [255]<br>
> > > > +  $ touch -t 200001010000 b<br>
> > > ><br>
> > ><br>
> > > I'm sorry I'm slow, but I'm still trying to understand this series. This<br>
> > is<br>
> > > of course an artificial way of reproducing the problem you were seeing,<br>
> > but<br>
> > > how does it sometimes happen in real life? Since the dirstate is written<br>
> > on<br>
> > > the 'hg status' call above, and that command is run after (not within the<br>
> > > same second, as we discussed on path 1/5) the file was modified on disk,<br>
> > > how can the 'hg merge' command be run at the earlier time again (which<br>
> > you<br>
> > > seem to be simulating here by setting the same timestamp)?<br>
> ><br>
> > Sorry for not enough explanation. I'll add more detailed explanation<br>
> > in revised version.<br>
> ><br>
> > Core of `hg update` and `hg merge` consists of steps below:<br>
> ><br>
> >   1. calculate result of updating and examine some additional points below<br>
> ><br>
> >      - `_checkunknownfiles()` (implied by `calculateupdates()`)<br>
> >      - `_checkcollision()`<br>
> ><br>
> >   2. update files in the working directory in `merge.applyupdates()`<br>
> ><br>
> >      this also implies updating files in subrepositories recursively<br>
> >      (= `preupdate`/`update` hooks in them are also executed)<br>
> ><br>
> >   3. update dirstate in `merge.recordupdates()`<br>
> ><br>
> >   4. write in-memory dirstate changes out at releasing wlock<br>
> ><br>
> ><br>
> > Tests in this patch emulate that `hg update` and `hg merge` (at top of<br>
> > subrepo tree) are aborted between (2) and (3) by:<br>
> ><br>
> >   - invalid updating in subrepositories<br>
> ><br>
> >     for example:<br>
> >     - uncommitted changes<br>
> >     - collision against unknown files in the working directory<br>
> >     - case-insensitive collision between files in new revision (and<br>
> >       current one at merging)<br>
> >     - failure of `preupdate` or `update` hooks<br>
> ><br>
> >   - keyboard interruption by user, file I/O error and so on<br>
> ><br>
> > `test-subrepo.t` actually treats the former situation, and<br>
> > 6becb9dbca25 tried to fix (part of) this issue. Tests in this patch<br>
> > can be said as "generalized version of test in 6becb9dbca25".<br>
> ><br>
> ><br>
> > Even though some existing tests are enough as a white box test<br>
> > examining whether `repo.wwrite()` invokes `dirstate.unsureifambig()`<br>
> > correctly, testing in multiple situations should be useful to avoid<br>
> > unexpected regression in the future, IMHO.<br>
> ><br>
> ><br>
> ><br>
> > > > +  $ cat b<br>
> > > > +  THIS IS FILE B5<br>
> > > > +  $ hg status -A b<br>
> > > > +  M b<br>
> > > > +<br>
> > > > +(file merged from other revision)<br>
> > > > +<br>
> > > > +  $ hg update -q -C 3<br>
> > > > +  $ echo 'this is file b6' > b<br>
> > > > +  $ hg commit -m 'commit #6'<br>
> > > > +  created new head<br>
> > > > +  $ touch -t 200001010000 b<br>
> > > > +  $ hg status -A b<br>
> > > > +  C b<br>
> > > > +  $ cat b<br>
> > > > +  this is file b6<br>
> > > > +<br>
> > > > +  $ hg --config extensions.abort=$TESTTMP/abort.py merge --tool<br>
> > > > internal:other 5<br>
> > > > +  abort: intentional aborting<br>
> > > > +  [255]<br>
> > > > +  $ touch -t 200001010000 b<br>
> > > > +  $ cat b<br>
> > > > +  THIS IS FILE B5<br>
> > > > +  $ hg status -A b<br>
> > > > +  M b<br>
> > > > +<br>
> > > >    $ cd ..<br>
> > > > _______________________________________________<br>
> > > > Mercurial-devel mailing list<br>
> > > > <a href="mailto:Mercurial-devel@selenic.com" target="_blank">Mercurial-devel@selenic.com</a><br>
> > > > <a href="https://selenic.com/mailman/listinfo/mercurial-devel" target="_blank">https://selenic.com/mailman/listinfo/mercurial-devel</a><br>
> > > ><br>
> > > [2  <text/html; UTF-8 (quoted-printable)>]<br>
> > ><br>
> ><br>
> > ----------------------------------------------------------------------<br>
> > [FUJIWARA Katsunori]                             <a href="mailto:foozy@lares.dti.ne.jp" target="_blank">foozy@lares.dti.ne.jp</a><br>
> ><br>
> [2  <text/html; UTF-8 (quoted-printable)>]<br>
><br>
<br>
----------------------------------------------------------------------<br>
[FUJIWARA Katsunori]                             <a href="mailto:foozy@lares.dti.ne.jp" target="_blank">foozy@lares.dti.ne.jp</a><br>
</blockquote></div></div>