Patchwork [v3] update: enable copy tracing for backwards and non-linear updates

login
register
mail settings
Submitter Gábor Stefanik
Date Oct. 17, 2016, 6:27 p.m.
Message ID <a41abe53dbc2c28d3b65.1476728849@GSTEFANIK.NavnGo.local>
Download mbox | patch
Permalink /patch/17156/
State Accepted
Headers show

Comments

Gábor Stefanik - Oct. 17, 2016, 6:27 p.m.
# HG changeset patch
# User Gábor Stefanik <gabor.stefanik@nng.com>
# Date 1472155346 -7200
#      Thu Aug 25 22:02:26 2016 +0200
# Node ID a41abe53dbc2c28d3b656f2a138da26949cf91d3
# Parent  3fc51a50bec71bb34c11beaaa6686d521ac706b1
update: enable copy tracing for backwards and non-linear updates

As a followup to the issue4028 series, this fixes a variant of the issue
that can occur when updating with uncommited local changes.

The duplicated .hgsub warning is coming from wc.dirty(). We would previously
skip this call because it's only relevant when we're going to perform copy
tracing, which we didn't do before.

The change to the update summary line is because we now treat the rename as a
proper rename (which counts as a change), rather than an add+delete pair
(which counts as a change and a delete).
Pierre-Yves David - Oct. 17, 2016, 8:41 p.m.
On 10/17/2016 08:55 PM, Kevin Bullock wrote:
>> On Oct 17, 2016, at 13:45, Gábor STEFANIK <Gabor.STEFANIK@nng.com> wrote:
>>
>> -----Original Message-----
>>> From: Kevin Bullock [mailto:kbullock+mercurial@ringworld.org]
>>> Sent: Monday, October 17, 2016 8:37 PM
>>> To: Gábor STEFANIK <Gabor.STEFANIK@nng.com>
>>> Cc: mercurial-devel@mercurial-scm.org
>>> Subject: Re: [PATCH v3] update: enable copy tracing for backwards and non-
>>> linear updates
>>>
>>>> On Oct 17, 2016, at 13:27, Gábor Stefanik <gabor.stefanik@nng.com>
>>> wrote:
>>>>
>>>> # HG changeset patch
>>>> # User Gábor Stefanik <gabor.stefanik@nng.com> # Date 1472155346 -7200
>>>> #      Thu Aug 25 22:02:26 2016 +0200
>>>> # Node ID a41abe53dbc2c28d3b656f2a138da26949cf91d3
>>>> # Parent  3fc51a50bec71bb34c11beaaa6686d521ac706b1
>>>> update: enable copy tracing for backwards and non-linear updates
>>>
>>> Urk. It's generally confusing to send just one updated patch to the end of an
>>> in-flight series (but it's good you at least flagged it v3).
>>>
>>> Since 1-7 of the v2 series are queued already, can you resend current
>>> versions of 8-12 as a v4?
>>
>> Done.
>>
>> It was Pierre-Yves's request to separate the last patch from the series, since it's not related to graft.
>> But if there's disagreement on this, I'm more than happy to have it treated as part of the series.

Actually, my initial request was to not include this one in the original 
batch (and I missed the fact he did) and then to send that one when the 
first series would be in.

However, This patch seems to work just fine with only the initial first 
5 that are pushed. So resending it independently was a good idea.

So despite the general confusion on various sides, the end result of 
Gábor sending this on its own ended up being pretty good. I've pushed 
this patch.

> Fair enough, I wasn't aware of that. In that case I would've said to resend just 8-11, but it's fine that you resent them as one chunk.

For the record, I would have preferred that part of the series to not be 
sent again as a V4. The V2 was still in review and no change had been 
requested to it. Having it resent is increasing list traffic, patch 
tracking work and confusion on my side for no visible benefit.
Kevin, any reason why you requested that ?

Cheers,
Pierre-Yves David - Oct. 17, 2016, 8:45 p.m.
On 10/17/2016 10:41 PM, Pierre-Yves David wrote:
>
>
> On 10/17/2016 08:55 PM, Kevin Bullock wrote:
>>> On Oct 17, 2016, at 13:45, Gábor STEFANIK <Gabor.STEFANIK@nng.com>
>>> wrote:
>>>
>>> -----Original Message-----
>>>> From: Kevin Bullock [mailto:kbullock+mercurial@ringworld.org]
>>>> Sent: Monday, October 17, 2016 8:37 PM
>>>> To: Gábor STEFANIK <Gabor.STEFANIK@nng.com>
>>>> Cc: mercurial-devel@mercurial-scm.org
>>>> Subject: Re: [PATCH v3] update: enable copy tracing for backwards
>>>> and non-
>>>> linear updates
>>>>
>>>>> On Oct 17, 2016, at 13:27, Gábor Stefanik <gabor.stefanik@nng.com>
>>>> wrote:
>>>>>
>>>>> # HG changeset patch
>>>>> # User Gábor Stefanik <gabor.stefanik@nng.com> # Date 1472155346 -7200
>>>>> #      Thu Aug 25 22:02:26 2016 +0200
>>>>> # Node ID a41abe53dbc2c28d3b656f2a138da26949cf91d3
>>>>> # Parent  3fc51a50bec71bb34c11beaaa6686d521ac706b1
>>>>> update: enable copy tracing for backwards and non-linear updates
>>>>
>>>> Urk. It's generally confusing to send just one updated patch to the
>>>> end of an
>>>> in-flight series (but it's good you at least flagged it v3).
>>>>
>>>> Since 1-7 of the v2 series are queued already, can you resend current
>>>> versions of 8-12 as a v4?
>>>
>>> Done.
>>>
>>> It was Pierre-Yves's request to separate the last patch from the
>>> series, since it's not related to graft.
>>> But if there's disagreement on this, I'm more than happy to have it
>>> treated as part of the series.
>
> Actually, my initial request was to not include this one in the original
> batch (and I missed the fact he did) and then to send that one when the
> first series would be in.
>
> However, This patch seems to work just fine with only the initial first
> 5 that are pushed. So resending it independently was a good idea.
>
> So despite the general confusion on various sides, the end result of
> Gábor sending this on its own ended up being pretty good. I've pushed
> this patch.
>
>> Fair enough, I wasn't aware of that. In that case I would've said to
>> resend just 8-11, but it's fine that you resent them as one chunk.
>
> For the record, I would have preferred that part of the series to not be
> sent again as a V4. The V2 was still in review and no change had been
> requested to it. Having it resent is increasing list traffic, patch
> tracking work and confusion on my side for no visible benefit.
> Kevin, any reason why you requested that ?

Ha, I just connected the dots. A V4 was sent to contains the update to 
the last patch. I got confused because that patch was in my mind 
independent and not included in that series at all. Sorry for the 
confusion and associated grumpyness.

Cheers,
Pierre-Yves David - Oct. 17, 2016, 8:54 p.m.
On 10/17/2016 10:52 PM, Kevin Bullock wrote:
>> On Oct 17, 2016, at 15:51, Kevin Bullock <kbullock+mercurial@ringworld.org> wrote:
>>
>>> On Oct 17, 2016, at 15:45, Pierre-Yves David <pierre-yves.david@ens-lyon.org> wrote:
>>>
>>> On 10/17/2016 10:41 PM, Pierre-Yves David wrote:
>>>>
>>>> On 10/17/2016 08:55 PM, Kevin Bullock wrote:
>>>>> Fair enough, I wasn't aware of that. In that case I would've said to
>>>>> resend just 8-11, but it's fine that you resent them as one chunk.
>>>>
>>>> For the record, I would have preferred that part of the series to not be
>>>> sent again as a V4. The V2 was still in review and no change had been
>>>> requested to it. Having it resent is increasing list traffic, patch
>>>> tracking work and confusion on my side for no visible benefit.
>>>> Kevin, any reason why you requested that ?
>>>
>>> Ha, I just connected the dots. A V4 was sent to contains the update to the last patch. I got confused because that patch was in my mind independent and not included in that series at all. Sorry for the confusion and associated grumpyness.
>>
>> Yeah, I was just trying to establish positively what part of the series was still active. Once part of a series is queued and another part is sliced off as a separate patch, I and our review tooling are both likely to drop the remainder on the floor (whether that's the intent or not).
>>
>> As I understand it now, you've queued #5 out of v4 and the rest of v4 is still under review. Is that right?
>
> ...and sometime soon we'll have improved tooling that can understand queuing non-contiguous parts of a series.

Yep, I've queued patch #5 of the v4 (because I picked it up when it was 
Patch 1 of another series (flagged V3)).

Does this confusing statement lift your confusion?

Patch

diff -r 3fc51a50bec7 -r a41abe53dbc2 mercurial/merge.py
--- a/mercurial/merge.py	Tue Oct 11 04:39:47 2016 +0200
+++ b/mercurial/merge.py	Thu Aug 25 22:02:26 2016 +0200
@@ -1555,15 +1555,16 @@ 
                     pas = [p1]
 
         # deprecated config: merge.followcopies
-        followcopies = False
+        followcopies = repo.ui.configbool('merge', 'followcopies', True)
         if overwrite:
             pas = [wc]
+            followcopies = False
         elif pas == [p2]: # backwards
-            pas = [wc.p1()]
-        elif not branchmerge and not wc.dirty(missing=True):
-            pass
-        elif pas[0] and repo.ui.configbool('merge', 'followcopies', True):
-            followcopies = True
+            pas = [p1]
+        elif not pas[0]:
+            followcopies = False
+        if not branchmerge and not wc.dirty(missing=True):
+            followcopies = False
 
         ### calculate phase
         actionbyfile, diverge, renamedelete = calculateupdates(
diff -r 3fc51a50bec7 -r a41abe53dbc2 tests/test-merge-local.t
--- a/tests/test-merge-local.t	Tue Oct 11 04:39:47 2016 +0200
+++ b/tests/test-merge-local.t	Thu Aug 25 22:02:26 2016 +0200
@@ -66,7 +66,7 @@ 
   merging zzz1_merge_ok
   merging zzz2_merge_bad
   warning: conflicts while merging zzz2_merge_bad! (edit, then use 'hg resolve --mark')
-  2 files updated, 1 files merged, 3 files removed, 1 files unresolved
+  2 files updated, 1 files merged, 2 files removed, 1 files unresolved
   use 'hg resolve' to retry unresolved file merges
   [1]
 
@@ -104,7 +104,7 @@ 
   merging zzz1_merge_ok
   merging zzz2_merge_bad
   warning: conflicts while merging zzz2_merge_bad! (edit, then use 'hg resolve --mark')
-  2 files updated, 1 files merged, 3 files removed, 1 files unresolved
+  2 files updated, 1 files merged, 2 files removed, 1 files unresolved
   use 'hg resolve' to retry unresolved file merges
   [1]
 
diff -r 3fc51a50bec7 -r a41abe53dbc2 tests/test-mq-subrepo.t
--- a/tests/test-mq-subrepo.t	Tue Oct 11 04:39:47 2016 +0200
+++ b/tests/test-mq-subrepo.t	Thu Aug 25 22:02:26 2016 +0200
@@ -304,6 +304,7 @@ 
   record this change to '.hgsub'? [Ynesfdaq?] y
   
   warning: subrepo spec file '.hgsub' not found
+  warning: subrepo spec file '.hgsub' not found
   abort: uncommitted changes in subrepository 'sub'
   [255]
   % update substate when adding .hgsub w/clean updated subrepo
@@ -319,6 +320,7 @@ 
   record this change to '.hgsub'? [Ynesfdaq?] y
   
   warning: subrepo spec file '.hgsub' not found
+  warning: subrepo spec file '.hgsub' not found
   path sub
    source   sub
    revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
diff -r 3fc51a50bec7 -r a41abe53dbc2 tests/test-up-local-change.t
--- a/tests/test-up-local-change.t	Tue Oct 11 04:39:47 2016 +0200
+++ b/tests/test-up-local-change.t	Thu Aug 25 22:02:26 2016 +0200
@@ -67,6 +67,10 @@ 
   summary:     2
   
   $ hg --debug up 0
+  starting 4 threads for background file closing (?)
+    searching for copies back to rev 0
+    unmatched files in local (from topological common ancestor):
+     b
   resolving manifests
    branchmerge: False, force: False, partial: False
    ancestor: 1e71731e6fbb, local: 1e71731e6fbb+, remote: c19d34741b0a
@@ -222,4 +226,20 @@ 
   1 files updated, 0 files merged, 0 files removed, 0 files unresolved
   $ hg st
 
+test updating backwards through a rename
+
+  $ hg mv a b
+  $ hg ci -m b
+  $ echo b > b
+  $ hg up -q 0
+  $ hg st
+  M a
+  $ hg diff --nodates
+  diff -r cb9a9f314b8b a
+  --- a/a
+  +++ b/a
+  @@ -1,1 +1,1 @@
+  -a
+  +b
+
   $ cd ..