[PATCH 1 of 2 stable] largefiles: test coverage of fatal interruption of update

[Mads Kiilerich]

# HG changeset patch
# User Mads Kiilerich 
# Date 1476577598 -7200
#  Sun Oct 16 02:26:38 2016 +0200
# Node ID 2105975810c843d016ba930c44e63699af2703a6
# Parent  5cb830801855dbb63e98b948e355bc995d295bf3
largefiles: test coverage of fatal interruption of update

Test using existing changesets in a clean working directory, revealing problems
with files that don't show up as modified or do show up as removed when they
just not have been written yet.

diff --git a/tests/test-largefiles-update.t b/tests/test-largefiles-update.t
--- a/tests/test-largefiles-update.t
+++ b/tests/test-largefiles-update.t
@@ -144,6 +144,7 @@ Test that "hg merge" updates largefiles 
   large1 in #1
   $ cat .hglf/large1
   58e24f733a964da346e2407a2bee99d9001184f5
+  $ rm normal1.orig
 
 (merge non-existing largefiles from "other" via conflict prompt -
 make sure the following commit doesn't abort in a confusing way when trying to
@@ -243,6 +244,7 @@ Test that "hg rollback" restores status 
   ? largeY
   $ test -f .hglf/largeY
   [1]
+  $ rm largeY
 
 Test that "hg rollback" restores standins correctly
 
@@ -285,6 +287,7 @@ is not branch-tip)
   58e24f733a964da346e2407a2bee99d9001184f5
   $ cat .hglf/large2
   1deebade43c8c498a3c8daddac0244dc55d1331d
+  $ rm normalX
 
 Test that "hg status" shows status of largefiles correctly just after
 automated commit like rebase/transplant
@@ -598,6 +601,7 @@ it is aborted by conflict.
   58e24f733a964da346e2407a2bee99d9001184f5
   $ cat large1
   large1 in #1
+  $ rm normal1.orig
 
 Test that rebase updates standins for manually modified largefiles at
 the 1st commit of resuming.
@@ -728,6 +732,48 @@ bit correctly on the platform being unaw
 
 #endif
 
+Test a fatal error interrupting an update. lfdirstate doesn't realize that
+.hglf has been updated while the largefile hasn't. Status thus shows a clean
+state ... but rebuilding lfdirstate and checking all hashes reveals it isn't
+clean.
+
+Start with clean dirstates:
+  $ hg up -qcr "8^"
+  $ sleep 1
+  $ hg st
+Update standins without updating largefiles:
+  $ cat << EOF > ../crashupdatelfiles.py
+  > import hgext.largefiles.lfutil
+  > def getlfilestoupdate(oldstandins, newstandins):
+  >  raise SystemExit(7)
+  > hgext.largefiles.lfutil.getlfilestoupdate = getlfilestoupdate
+  > EOF
+  $ hg up -Cr "8" --config extensions.crashupdatelfiles=../crashupdatelfiles.py
+  [7]
+Check large1 content and status:
+BUG: largeX is R and large1 is not M and update does nothing
+  $ cat large1
+  large1 in #3
+  $ hg st
+  R largeX
+  $ hg up -Cr .
+  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ hg st
+  R largeX
+Force largefiles rehashing and check again - revealing modifications that
+update now can remove:
+  $ rm .hg/largefiles/dirstate
+  $ hg st
+  M large1
+  ! largeX
+  $ hg up -Cr .
+  getting changed largefiles
+  2 largefiles updated, 0 removed
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ hg st
+  $ cat large1
+  manually modified before 'hg transplant --continue'
+
   $ cd ..
 
 Test that "hg convert" avoids copying largefiles from the working
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 2 stable] largefiles: more safe handling of interruptions while updating modifications

[Mads Kiilerich]

# HG changeset patch
# User Mads Kiilerich 
# Date 1476577785 -7200
#  Sun Oct 16 02:29:45 2016 +0200
# Node ID dcd190cb73a0740be570bdfbc1090066c38e1173
# Parent  2105975810c843d016ba930c44e63699af2703a6
largefiles: more safe handling of interruptions while updating modifications

Largefiles are fragile with the design where dirstate and lfdirstate must be
kept in sync.

To be less fragile, mark all clean largefiles as unsure ("normallookup") before
updating standins. After standins have been updated and we know exactly which
largefile standins actually was changed, mark the unchanged largefiles back to
clean ("normal").

This will make the failure mode more safe. If interrupted, the next command
will continue to perform extra hashing of all largefiles. That will do that all
largefiles that are out of sync with their standin will be marked dirty and
they will show up in status and can be cleaned with update --clean.

diff --git a/hgext/largefiles/overrides.py b/hgext/largefiles/overrides.py
--- a/hgext/largefiles/overrides.py
+++ b/hgext/largefiles/overrides.py
@@ -1385,7 +1385,8 @@ def mergeupdate(orig, repo, node, branch
 lfdirstate = lfutil.openlfdirstate(repo.ui, repo)
 unsure, s = lfdirstate.status(matchmod.always(repo.root,
 repo.getcwd()),
-  [], False, False, False)
+  [], False, True, False)
+oldclean = set(s.clean)
 pctx = repo['.']
 for lfile in unsure + s.modified:
 lfileabs = repo.wvfs.join(lfile)
@@ -1397,9 +1398,13 @@ def mergeupdate(orig, repo, node, branch
 lfutil.getexecutable(lfileabs))
 if (standin in pctx and
 lfhash == lfutil.readstandin(repo, lfile, '.')):
-lfdirstate.normal(lfile)
+oldclean.add(lfile)
 for lfile in s.added:
 lfutil.updatestandin(repo, lfutil.standin(lfile))
+# mark all clean largefiles as dirty, just in case the update gets
+# interrupted before largefiles and lfdirstate are synchronized
+for lfile in oldclean:
+lfdirstate.normallookup(lfile)
 lfdirstate.write()
 
 oldstandins = lfutil.getstandinsstate(repo)
@@ -1408,6 +1413,13 @@ def mergeupdate(orig, repo, node, branch
 
 newstandins = lfutil.getstandinsstate(repo)
 filelist = lfutil.getlfilestoupdate(oldstandins, newstandins)
+
+# to avoid leaving all largefiles as dirty and thus rehash them, mark
+# all the ones that didn't change as clean
+for lfile in oldclean.difference(filelist):
+lfdirstate.normal(lfile)
+lfdirstate.write()
+
 if branchmerge or force or partial:
 filelist.extend(s.deleted + s.removed)
 
diff --git a/tests/test-largefiles-update.t b/tests/test-largefiles-update.t
--- a/tests/test-largefiles-update.t
+++ b/tests/test-largefiles-update.t
@@ -732,16 +732,16 @@ bit correctly on the platform being unaw
 
 #endif
 
-Test a fatal error interrupting an update. lfdirstate doesn't realize that
-.hglf has been updated while the largefile hasn't. Status thus shows a clean
-state ... but rebuilding lfdirstate and checking all hashes reveals it isn't
-clean.
+Test a fatal error interrupting an update. Verify that status report dirty
+files correctly after an interrupted update. Also verify that checking all
+hashes reveals it isn't clean.
 
 Start with clean dirstates:
   $ hg up -qcr "8^"
   $ sleep 1
   $ hg st
-Update standins without updating largefiles:
+Update standins without updating largefiles - large1 is modified and largeX is
+added:
   $ cat << EOF > ../crashupdatelfiles.py
   > import hgext.largefiles.lfutil
   > def getlfilestoupdate(oldstandins, newstandins):
@@ -750,29 +750,31 @@ Update standins without updating largefi
   > EOF
   $ hg up -Cr "8" --config extensions.crashupdatelfiles=../crashupdatelfiles.py
   [7]
-Check large1 content and status:
-BUG: largeX is R and large1 is not M and update does nothing
+Check large1 content and status ... and that update will undo modifications:
+BUG: large is R
   $ cat large1
   large1 in #3
   $ hg st
+  M large1
   R largeX
   $ hg up -Cr .
-  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  getting changed largefiles
+  1 largefiles updated, 0 removed
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cat large1
+  manually modified before 'hg transplant --continue'
   $ hg st
   R largeX
-Force largefiles rehashing and check again - revealing modifications that
-update now can remove:
+Force largefiles rehashing and check again - which makes it realize that largeX
+not has been removed but just doesn't exist:
   $ rm .hg/largefiles/dirstate
   $ hg st
-  M large1
   ! largeX
   $ hg up -Cr .
   getting changed largefiles
-  2 largefiles updated, 0 removed
-  

[PATCH] color: add some documentation for custom terminfo codes

[danek . duvall]

# HG changeset patch
# User Danek Duvall 
# Date 1476568874 25200
#  Sat Oct 15 15:01:14 2016 -0700
# Node ID 42f5a2db9e7f9d66058a7d77bc8c0c263272a8de
# Parent  c59334b806a8f10c80c2ea196eba5f4b1b86b229
color: add some documentation for custom terminfo codes

diff --git a/hgext/color.py b/hgext/color.py
--- a/hgext/color.py
+++ b/hgext/color.py
@@ -29,6 +29,15 @@ ECMA-48 mode, the options are 'bold', 'i
 Some may not be available for a given terminal type, and will be
 silently ignored.
 
+If the terminfo entry for your terminal is missing codes for an effect
+or has the wrong codes, you can add or override those codes in your
+configuration::
+
+  [color]
+  terminfo.dim = \E[2m
+
+where '\E' is substituted with an escape character.
+
 Labels
 --
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3] color: debugcolor should emit the user-defined colors

[Danek Duvall]

Yuya Nishihara wrote:

> On Thu, 13 Oct 2016 13:27:35 -0700, danek.duv...@oracle.com wrote:
> > # HG changeset patch
> > # User Danek Duvall 
> > # Date 1476389401 25200
> > #  Thu Oct 13 13:10:01 2016 -0700
> > # Node ID c59334b806a8f10c80c2ea196eba5f4b1b86b229
> > # Parent  333e875ce30da3760c8655e303d9bea554efe7e4
> > color: debugcolor should emit the user-defined colors
> > 
> > This also fixes a long-standing bug that reversed the sense of the color
> > name and the label used to print it, which was never relevant before.
> > 
> > diff --git a/hgext/color.py b/hgext/color.py
> > --- a/hgext/color.py
> > +++ b/hgext/color.py
> > @@ -524,10 +524,16 @@ def debugcolor(ui, repo, **opts):
> >  _styles = {}
> >  for effect in _effects.keys():
> >  _styles[effect] = effect
> > +if _terminfo_params:
> > +for k, v in ui.configitems('color'):
> > +if k.startswith('color.'):
> > +_styles[k] = k[6:]
> > +elif k.startswith('terminfo.'):
> > +_styles[k] = k[9:]
> >  ui.write(('color mode: %s\n') % ui._colormode)
> >  ui.write(_('available colors:\n'))
> > -for label, colors in _styles.items():
> > -ui.write(('%s\n') % colors, label=label)
> > +for colorname, label in _styles.items():
> > +ui.write(('%s\n') % colorname, label=label)
> 
> I was surprised to know that a label can be a valid effect name.

This bit confused me for a while, and maybe I didn't make things better in
that regard.  There's "label" in the sense of the keyword argument to
ui.write(), and "label" in the sense of the word that we're printing out
here, labelling the color.  I used the latter sense in my comment, but the
code uses the former sense.

Danek
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 3] color: allow for user-configurable terminfo codes for effects

[Danek Duvall]

Yuya Nishihara wrote:

> On Thu, 13 Oct 2016 13:27:33 -0700, danek.duv...@oracle.com wrote:
> > # HG changeset patch
> > # User Danek Duvall 
> > # Date 1476384497 25200
> > #  Thu Oct 13 11:48:17 2016 -0700
> > # Node ID 61e74a19770c2ce80c0cedc429915112261e5c1b
> > # Parent  4d93d73b8aecb2436bbfe9248cdfe0ef21582baf
> > color: allow for user-configurable terminfo codes for effects
> 
> The series looks good to me. Queued, thanks.

Thanks!

> > If the entry in the terminfo database for your terminal is missing some
> > attributes, it should be possible to create them on the fly without
> > resorting to just making them a color.  This change allows you to have
> > 
> > [color]
> > terminfo. = 
> > 
> > where  might be something like "dim" or "bold", and  is the
> > escape sequence that would otherwise have come from a call to tigetstr().
> > If an escape character is needed, use "\E".  Any such settings will
> > override attributes that are present in the terminfo database.
> 
> Can you update the doc as a follow-up?

Patch should be on its way.

Thanks,
Danek
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 3] color: allow for user-configurable terminfo codes for effects

[Yuya Nishihara]

On Thu, 13 Oct 2016 13:27:33 -0700, danek.duv...@oracle.com wrote:
> # HG changeset patch
> # User Danek Duvall 
> # Date 1476384497 25200
> #  Thu Oct 13 11:48:17 2016 -0700
> # Node ID 61e74a19770c2ce80c0cedc429915112261e5c1b
> # Parent  4d93d73b8aecb2436bbfe9248cdfe0ef21582baf
> color: allow for user-configurable terminfo codes for effects

The series looks good to me. Queued, thanks.

> If the entry in the terminfo database for your terminal is missing some
> attributes, it should be possible to create them on the fly without
> resorting to just making them a color.  This change allows you to have
> 
> [color]
> terminfo. = 
> 
> where  might be something like "dim" or "bold", and  is the
> escape sequence that would otherwise have come from a call to tigetstr().
> If an escape character is needed, use "\E".  Any such settings will
> override attributes that are present in the terminfo database.

Can you update the doc as a follow-up?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 3] cmdutil: add support for evolution "troubles" display in changeset_printer

[Yuya Nishihara]

On Mon, 10 Oct 2016 14:33:18 +0200, Denis Laxalde wrote:
> # HG changeset patch
> # User Denis Laxalde 
> # Date 1476094018 -7200
> #  Mon Oct 10 12:06:58 2016 +0200
> # Node ID d9f7776c40b8c82bf438322f2442d99c4e116161
> # Parent  6c916ce602f5c92c5a5a4de954629670b8c7ca8c
> # EXP-Topic evolve-ui
> cmdutil: add support for evolution "troubles" display in changeset_printer
> 
> Add a "troubles" line in changeset header along with a couple of labels on
> "log.changeset" line to indicate whether a changeset is troubled or not and
> which kind trouble occurs.
> 
> Extract a _changesetlabels function to be reused in summary command.
> 
> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
> --- a/mercurial/cmdutil.py
> +++ b/mercurial/cmdutil.py
> @@ -1204,6 +1204,14 @@ def diffordiffstat(ui, repo, diffopts, n
>  sub.diff(ui, diffopts, tempnode2, submatch, changes=changes,
>   stat=stat, fp=fp, prefix=prefix)
>  
> +def _changesetlabels(ctx):
> +labels = ['log.changeset', 'changeset.%s' % ctx.phasestr()]
> +if ctx.troubled():
> +labels.append('changeset.troubled')
> +for trouble in ctx.troubles():
> +labels.append('trouble.%s' % trouble)
> +return ' '.join(labels)
> +
>  class changeset_printer(object):
>  '''show changeset information when templating not requested.'''
>  
> @@ -1264,7 +1272,7 @@ class changeset_printer(object):
>  
>  # i18n: column positioning for "hg log"
>  self.ui.write(_("changeset:   %d:%s\n") % revnode,
> -  label='log.changeset changeset.%s' % ctx.phasestr())
> +  label=_changesetlabels(ctx))
>  
>  # branches are shown first before any other names due to backwards
>  # compatibility
> @@ -1309,6 +1317,10 @@ class changeset_printer(object):
>  self.ui.write(_("date:%s\n") % date,
>label='log.date')
>  
> +if ctx.troubled():
> +self.ui.write(_("troubles:%s\n") % ', '.join(ctx.troubles()),
> +  label='ui.note log.troubles')

The change looks good, but I have no idea if we can expose "troubles",
"troubled", etc. as a public API. I have a vague memory someone saying
"trouble" sounds trange to native speakers.

And we'll need to update templates/map-cmdline.default to reflect this change.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH V5] update: warn if cwd was deleted

[Yuya Nishihara]

On Tue, 4 Oct 2016 04:08:42 -0700, Stanislau Hlebik wrote:
> # HG changeset patch
> # User Stanislau Hlebik 
> # Date 1475579208 25200
> #  Tue Oct 04 04:06:48 2016 -0700
> # Node ID 9069c255f60c9d34e5f45d690cfa9316fdc71722
> # Parent  1779dde4c9ef97cb242f8d501655f236f66e5439
> update: warn if cwd was deleted

Looks good to me per comments on V3 and V4. Queued, thanks.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@30162: 12 new changesets

[Mercurial Commits]

12 new changesets in mercurial:

http://selenic.com/repo/hg//rev/381293e1135e
changeset:   30151:381293e1135e
user:Augie Fackler 
date:Mon Sep 19 17:15:39 2016 -0400
summary: copy: distinguish "file exists" cases and add a hint (BC)

http://selenic.com/repo/hg//rev/d65e246100ed
changeset:   30152:d65e246100ed
user:Pierre-Yves David 
date:Sun Oct 09 03:11:18 2016 +0200
summary: help: backout f3c4edfd35e1 (mark boolean flags with [no-] in help) 
for now

http://selenic.com/repo/hg//rev/edb49a90723c
changeset:   30153:edb49a90723c
user:Gregory Szorc 
date:Thu Oct 13 12:49:47 2016 +0200
summary: changegroup: document deltaparent's choice of previous revision

http://selenic.com/repo/hg//rev/5e72129d75ed
changeset:   30154:5e72129d75ed
user:Gregory Szorc 
date:Sat Sep 24 12:25:37 2016 -0700
summary: revlog: add instance variable controlling delta chain use

http://selenic.com/repo/hg//rev/b7a966ce89ed
changeset:   30155:b7a966ce89ed
user:Gregory Szorc 
date:Thu Oct 13 12:50:27 2016 +0200
summary: changelog: disable delta chains

http://selenic.com/repo/hg//rev/75c71c533977
changeset:   30156:75c71c533977
user:Mads Kiilerich 
date:Fri Oct 14 03:03:39 2016 +0200
summary: demandimport: disable lazy import of __builtin__

http://selenic.com/repo/hg//rev/df224038c516
changeset:   30157:df224038c516
user:Philippe Pepiot 
date:Fri Oct 14 09:52:38 2016 +0200
summary: commit: return 1 for interactive commit with no changes (issue5397)

http://selenic.com/repo/hg//rev/1baa0e2cfc37
changeset:   30158:1baa0e2cfc37
user:Philippe Pepiot 
date:Wed Oct 12 12:22:54 2016 +0200
summary: record: return code from underlying commit

http://selenic.com/repo/hg//rev/fb5504d7b2c9
changeset:   30159:fb5504d7b2c9
user:Gregory Szorc 
date:Sat Oct 08 17:07:43 2016 +0200
summary: dirs: document Py_SIZE weirdness

http://selenic.com/repo/hg//rev/008c4ce64e3f
changeset:   30160:008c4ce64e3f
user:Mads Kiilerich 
date:Wed Oct 12 12:22:18 2016 +0200
summary: tests: add test coverage of merging x flag without ancestor

http://selenic.com/repo/hg//rev/339f9d93daa6
changeset:   30161:339f9d93daa6
user:Mads Kiilerich 
date:Wed Oct 12 12:22:18 2016 +0200
summary: merge: only show "cannot merge flags for %s" warning if flags are 
different

http://selenic.com/repo/hg//rev/5cb830801855
changeset:   30162:5cb830801855
bookmark:@
tag: tip
user:Mads Kiilerich 
date:Wed Oct 12 12:22:18 2016 +0200
summary: merge: clarify warning for (not) merging flags without ancestor

-- 
Repository URL: http://selenic.com/repo/hg/
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 2 V3] py3: refactor token parsing to handle call args properly

[Martijn Pieters]

On 15 Oct 2016, at 08:39, Yuya Nishihara  wrote:
> 
> On Fri, 14 Oct 2016 17:55:25 +0100, Martijn Pieters wrote:
>> # HG changeset patch
>> # User Martijn Pieters 
>> # Date 1476464102 -3600
>> #  Fri Oct 14 17:55:02 2016 +0100
>> # Node ID 9031460519503abe5dc430c8ece29d198121cd65
>> # Parent  733fb9f7bc92c694ba6bededaeb93206528c0bcd
>> py3: refactor token parsing to handle call args properly
> 
> Queued them, thanks.
> 
>> +nested = 0
>> +for j in xrange(i + 2, len(tokens)):
> 
> s/xrange/range/ ;-)

Doh! I still had in my head the assumption the module import code would do this 
for us, except this **is** the module import code. *facepalm*.

--
Martijn


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 2 V3] py3: refactor token parsing to handle call args properly

[Yuya Nishihara]

On Fri, 14 Oct 2016 17:55:25 +0100, Martijn Pieters wrote:
> # HG changeset patch
> # User Martijn Pieters 
> # Date 1476464102 -3600
> #  Fri Oct 14 17:55:02 2016 +0100
> # Node ID 9031460519503abe5dc430c8ece29d198121cd65
> # Parent  733fb9f7bc92c694ba6bededaeb93206528c0bcd
> py3: refactor token parsing to handle call args properly

Queued them, thanks.

> +nested = 0
> +for j in xrange(i + 2, len(tokens)):

s/xrange/range/ ;-)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 6] dirs: use PyVarObject_HEAD_INIT

[Yuya Nishihara]

On Thu, 13 Oct 2016 21:44:13 +0200, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1476357254 -7200
> #  Thu Oct 13 13:14:14 2016 +0200
> # Node ID 1f30bcebd4bdc26602ec4e9ae924f101c7642594
> # Parent  c0410814002f467c24ef07ce73850ba15b306f8e
> dirs: use PyVarObject_HEAD_INIT

These look good. Queued, thanks.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Topics [was: news from the topic experiment]

[Yuya Nishihara]

On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote:
> Pierre-Yves David  writes:
> > So, the other branch of that thread made me realised that we cannot do 
> > this "BRANCH:TOPIC" storage in the current "branch" field.
> >
> > An important part of topic is to have them fade away when the changesets 
> > become public. This fading away will be implemented client side (logic 
> > to stop reading the value). If we expose this data to old client who 
> > does not have this logic this means that topic would live as 
> > "BRANCH:TOPIC" forever on old client, breaking them in various way.
> 
> I don't see that. Currently, we have:
> 
> - old client cannot see topic at all (making it unusable)
> - new client can see topics
> 
> If we move to branchname + flag, we have:
> 
> - old client can see and update using 'hg update NAME' (extremely
>   valuable)
> - old client can merge a topic to default (extremely helpful and surprising)
> - new client will hide those branches
> 
> Your argument is that old clients will see those branches. That's a much
> better side-effect than not being able to update at all to a topic
> branch.

I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding "BRANCH" is
bad because you can't filter log by "branch(BRANCH)" in old client.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] revset: for x^2, do not take null as a valid p2 revision

[Yuya Nishihara]

On Fri, 14 Oct 2016 18:42:12 +0200, Pierre-Yves David wrote:
> On 10/14/2016 05:35 PM, Yuya Nishihara wrote:
> > # HG changeset patch
> > # User Yuya Nishihara 
> > # Date 1476455580 -32400
> > #  Fri Oct 14 23:33:00 2016 +0900
> > # Node ID 18ba0036dd81db9e45fd1a450c7f207f1b89f22c
> > # Parent  5cb830801855dbb63e98b948e355bc995d295bf3
> > revset: for x^2, do not take null as a valid p2 revision
> >
> > Since we don't count null p2 revision as a parent, x^2 should never return
> > null even if null is explicitly populated.
> >
> > diff --git a/mercurial/revset.py b/mercurial/revset.py
> > --- a/mercurial/revset.py
> > +++ b/mercurial/revset.py
> > @@ -1620,7 +1620,7 @@ def parentspec(repo, subset, x, n, order
> >  ps.add(cl.parentrevs(r)[0])
> >  elif n == 2:
> >  parents = cl.parentrevs(r)
> > -if len(parents) > 1:
> > +if parents[1] != node.nullrev:
> 
> Is there any chance that p1 is nullid and p2 is not?

No.

> Also, how does this behave if r is a root (p1 and p2 is nullid).
> 
> Should we instead filter the parents list ?::
> 
>parents = [p for p in cl.parentrevs(r) if p != nullrev]

IMHO, that's undecided problem. It doesn't make sense to take p2=null as
a valid relation because otherwise all revisions must be rooted to null (b),
which doesn't agree with how we draw a graph including null (a).

  (a) -1 - 0 - 1 ...

  (b) -1 = 0 - 1
   \  /
--

But we could say '0^1' (or 'null:tip & 0^1') is null per the graph (a). So
I fixed only 'x^2 -> null', which is clearly wrong.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel