Patchwork [19,of,24] mq: stabilize update after strip of parent revision

login
register
mail settings
Submitter Mads Kiilerich
Date Dec. 16, 2012, 10:34 p.m.
Message ID <b03e365968f876ad504b.1355697254@localhost6.localdomain6>
Download mbox | patch
Permalink /patch/143/
State Accepted
Commit ff2c89ebf5d40134c0f61f9b83acec510047c8e7
Headers show

Comments

Mads Kiilerich - Dec. 16, 2012, 10:34 p.m.
# HG changeset patch
# User Mads Kiilerich <mads at kiilerich.com>
# Date 1355687458 -3600
# Node ID b03e365968f876ad504b324c93737434b9397731
# Parent  8e79a682878e79a4119dfd3e907476204ebd0f99
mq: stabilize update after strip of parent revision
Bryan O'Sullivan - Dec. 17, 2012, 9:08 p.m.
On Sun, Dec 16, 2012 at 2:34 PM, Mads Kiilerich <mads at kiilerich.com> wrote:

> mq: stabilize update after strip of parent revision
>

This is changing some test output that looks like it might be meaningful in
a way that I can't interpret, since I don't use glog. Maybe a little more
text about why this is safe?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121217/d4e133f7/attachment.html>
Kevin Bullock - Dec. 17, 2012, 9:25 p.m.
On Dec 17, 2012, at 3:08 PM, Bryan O'Sullivan wrote:

> On Sun, Dec 16, 2012 at 2:34 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> mq: stabilize update after strip of parent revision
> 
> This is changing some test output that looks like it might be meaningful in a way that I can't interpret, since I don't use glog. Maybe a little more text about why this is safe?

This appears to (possibly) fix an actual bug. With graphlog, the '@' marks the parent(s) of the working dir. In the current test, the working dir ends up on a revision that isn't an ancestor of the working dir before the strip.

What I'm wondering, though, is does it actually fix the bug? After this change, will the working dir deterministically end up on an ancestor of where it was before?

pacem in terris / ??? / ?????? / ????????? / ??
Kevin R. Bullock
Mads Kiilerich - Dec. 18, 2012, 1:50 a.m.
> # HG changeset patch
> # User Mads Kiilerich<mads at kiilerich.com>
> # Date 1355687458 -3600
> # Node ID b03e365968f876ad504b324c93737434b9397731
> # Parent  8e79a682878e79a4119dfd3e907476204ebd0f99
> mq: stabilize update after strip of parent revision
>
> diff --git a/hgext/mq.py b/hgext/mq.py
> --- a/hgext/mq.py
> +++ b/hgext/mq.py
> @@ -3042,7 +3042,7 @@
>               del q.applied[start:end]
>               q.savedirty()
>   
> -    revs = list(rootnodes)
> +    revs = sorted(rootnodes)
>       if update and opts.get('keep'):
>           wlock = repo.wlock()
>           try:
> diff --git a/tests/test-mq-strip.t b/tests/test-mq-strip.t
> --- a/tests/test-mq-strip.t
> +++ b/tests/test-mq-strip.t
> @@ -309,16 +309,16 @@
>   2 different branches: 2 strips
>   
>     $ hg strip 2 4
> -  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> +  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>     saved backup bundle to $TESTTMP/test/.hg/strip-backup/*-backup.hg (glob)
>     $ hg glog
> -  @  changeset:   2:65bd5f99a4a3
> +  o  changeset:   2:65bd5f99a4a3
>     |  tag:         tip
>     |  user:        test
>     |  date:        Thu Jan 01 00:00:00 1970 +0000
>     |  summary:     d
>     |
> -  o  changeset:   1:ef3a871183d7
> +  @  changeset:   1:ef3a871183d7
>     |  user:        test
>     |  date:        Thu Jan 01 00:00:00 1970 +0000
>     |  summary:     b

Kevin Bullock wrote, On 12/17/2012 10:25 PM:
> On Dec 17, 2012, at 3:08 PM, Bryan O'Sullivan wrote:
>> This is changing some test output that looks like it might be meaningful in a way that I can't interpret, since I don't use glog. Maybe a little more text about why this is safe?
> This appears to (possibly) fix an actual bug. With graphlog, the '@' marks the parent(s) of the working dir. In the current test, the working dir ends up on a revision that isn't an ancestor of the working dir before the strip.
>
> What I'm wondering, though, is does it actually fix the bug? After this change, will the working dir deterministically end up on an ancestor of where it was before?

Strip will update to the parent of revs[0] (if it updates), where revs 
are the roots of the tree that is stripped.

When revs was list(set) it was thus undefined which root parent it would 
update to. With sorted(set) it is at least stable what it updates to. 
But it is very possible that another more useful and predicable 
behaviour could be defined.

I will thus not consider it a bugfix, just a fix for exposing undefined 
"random" behaviour.

/Mads

Patch

diff --git a/hgext/mq.py b/hgext/mq.py
--- a/hgext/mq.py
+++ b/hgext/mq.py
@@ -3042,7 +3042,7 @@ 
             del q.applied[start:end]
             q.savedirty()
 
-    revs = list(rootnodes)
+    revs = sorted(rootnodes)
     if update and opts.get('keep'):
         wlock = repo.wlock()
         try:
diff --git a/tests/test-mq-strip.t b/tests/test-mq-strip.t
--- a/tests/test-mq-strip.t
+++ b/tests/test-mq-strip.t
@@ -309,16 +309,16 @@ 
 2 different branches: 2 strips
 
   $ hg strip 2 4
-  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
   saved backup bundle to $TESTTMP/test/.hg/strip-backup/*-backup.hg (glob)
   $ hg glog
-  @  changeset:   2:65bd5f99a4a3
+  o  changeset:   2:65bd5f99a4a3
   |  tag:         tip
   |  user:        test
   |  date:        Thu Jan 01 00:00:00 1970 +0000
   |  summary:     d
   |
-  o  changeset:   1:ef3a871183d7
+  @  changeset:   1:ef3a871183d7
   |  user:        test
   |  date:        Thu Jan 01 00:00:00 1970 +0000
   |  summary:     b