Nice start! If I remember correctly, the mergestate stores the local version of the file. We can use that directly instead.

@durin42 I don't think the subrepos are properly initialized in the tests. I would be updating them soon.

In D6735#100392, @durin42 wrote:

This looks good to me. Does anyone else have comments? @mharbison72 are you happy with the subrepo test coverage?

I forgot about this, thanks for the reminder. @taapas1128 is correct- the subrepos aren't being initialized as subrepos (i.e. there's no .hgsub file). I'll try to play with this more Friday or over the weekend.

Here's a case I stumbled upon that is a problem. It looks like it thinks it isn't in the middle of an update, but .hgsubstate isn't put back to the pre-update state.

diff --git a/tests/test-subrepo.t b/tests/test-subrepo.t
--- a/tests/test-subrepo.t
+++ b/tests/test-subrepo.t
@@ -1027,10 +1027,38 @@ filesystem (see also issue4583))
   > [extensions]
   > fakedirstatewritetime = $TESTDIR/fakedirstatewritetime.py
   > EOF
+  $ hg -R repo st -S
+  ? s/b
+  $ hg -R repo diff -S
+  $ hg -R repo log -r .
+  changeset:   0:c4018e9aea1b
+  user:        test
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     1
+
+  $ cat repo/.hgsubstate
+  f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s
   $ hg -R repo update
   b: untracked file differs
   abort: untracked files in working directory differ from files in requested revision (in subrepository "s")
   [255]
+  $ hg -R repo update --abort
+  abort: no update in progress
+  [255]
+  $ hg -R repo diff -S
+  diff -r c4018e9aea1b .hgsubstate
+  --- a/.hgsubstate Thu Jan 01 00:00:00 1970 +0000
+  +++ b/.hgsubstate Thu Jan 01 00:00:00 1970 +0000
+  @@ -1,1 +1,1 @@
+  -f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s
+  +cc505f09a8b2644adffa368adb4abc6f70d07bc0 s
+  $ hg -R repo log -r .
+  changeset:   0:c4018e9aea1b
+  user:        test
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     1
+
+
   $ cat >> repo/.hg/hgrc <<EOF
   > [extensions]
   > fakedirstatewritetime = !

Another good way to induce this .hgsubstate issue is to hg pull -u on a repo, where the remote subrepo isn't available. You don't need http for this- you can just rename the remote subrepo.

In D6735#100642, @mharbison72 wrote:

Here's a case I stumbled upon that is a problem. It looks like it thinks it isn't in the middle of an update, but .hgsubstate isn't put back to the pre-update state.

diff --git a/tests/test-subrepo.t b/tests/test-subrepo.t
--- a/tests/test-subrepo.t
+++ b/tests/test-subrepo.t
@@ -1027,10 +1027,38 @@ filesystem (see also issue4583))
   > [extensions]
   > fakedirstatewritetime = $TESTDIR/fakedirstatewritetime.py
   > EOF
+  $ hg -R repo st -S
+  ? s/b
+  $ hg -R repo diff -S
+  $ hg -R repo log -r .
+  changeset:   0:c4018e9aea1b
+  user:        test
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     1
+
+  $ cat repo/.hgsubstate
+  f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s
   $ hg -R repo update
   b: untracked file differs
   abort: untracked files in working directory differ from files in requested revision (in subrepository "s")

@mharbison72 I am bit confused here.

1. Since hg -R repo update resulted with an abort then why we have dirty working directory now? Isn't transaction rollback worked correctly?
2. Also if you run hg status it says "To continue: run hg update ." but I don't think it's really a "continue", since we are still on the same changeset where we ran the first update command and running hg update . won't take us to the changeset we wanted to go.
3. I found that for interrupted update (only for some particular kind of interrupted update) we store target node value in .hg/updatestate but I couldn't find where we exactly use that value. I found some code which check if that file exists but not one where we use the value stored in that file.

[255]

+ $ hg -R repo update --abort
+ abort: no update in progress
+ [255]
+ $ hg -R repo diff -S
+ diff -r c4018e9aea1b .hgsubstate
+ --- a/.hgsubstate Thu Jan 01 00:00:00 1970 +0000
+ +++ b/.hgsubstate Thu Jan 01 00:00:00 1970 +0000
+ @@ -1,1 +1,1 @@
+ -f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s
+ +cc505f09a8b2644adffa368adb4abc6f70d07bc0 s
+ $ hg -R repo log -r .
+ changeset: 0:c4018e9aea1b
+ user: test
+ date: Thu Jan 01 00:00:00 1970 +0000
+ summary: 1
+
+

$ cat >> repo/.hg/hgrc <<EOF
> [extensions]
> fakedirstatewritetime = !

Another good way to induce this .hgsubstate issue is to `hg pull -u` on a repo, where the remote subrepo isn't available.  You don't need http for this- you can just rename the remote subrepo.

In D6735#123875, @khanchi97 wrote:

In D6735#100642, @mharbison72 wrote:

Here's a case I stumbled upon that is a problem. It looks like it thinks it isn't in the middle of an update, but .hgsubstate isn't put back to the pre-update state.

diff --git a/tests/test-subrepo.t b/tests/test-subrepo.t
--- a/tests/test-subrepo.t
+++ b/tests/test-subrepo.t
@@ -1027,10 +1027,38 @@ filesystem (see also issue4583))
   > [extensions]
   > fakedirstatewritetime = $TESTDIR/fakedirstatewritetime.py
   > EOF
+  $ hg -R repo st -S
+  ? s/b
+  $ hg -R repo diff -S
+  $ hg -R repo log -r .
+  changeset:   0:c4018e9aea1b
+  user:        test
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     1
+
+  $ cat repo/.hgsubstate
+  f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s
   $ hg -R repo update
   b: untracked file differs
   abort: untracked files in working directory differ from files in requested revision (in subrepository "s")

@mharbison72 I am bit confused here.

1. Since hg -R repo update resulted with an abort then why we have dirty working directory now? Isn't transaction rollback worked correctly?

Two things to keep in mind.

1. updates aren't transactions
2. even if they were, a transaction is within *one* repo.

When you update with subrepos, you check for dirty from the top, recurse to the bottom, and on the way up you update the subrepo. So in the simple case of parent repo P and subrepo S, you check P for dirty (recursively), then update S, then update P. If something goes wrong updating P, S is not rolled back.

2. Also if you run hg status it says "To continue: run hg update ." but I don't think it's really a "continue", since we are still on the same changeset where we ran the first update command and running hg update . won't take us to the changeset we wanted to go.

Maybe it needs to continue if it did a partial checkout? IDK when the parent in dirstate is updated- before or after all files are checked out.

3. I found that for interrupted update (only for some particular kind of interrupted update) we store target node value in .hg/updatestate but I couldn't find where we exactly use that value. I found some code which check if that file exists but not one where we use the value stored in that file.

Sorry, I'm not sure about that either. I'd imagine it's for the --continue case though. Maybe that isn't fully implemented yet?