Pulkit Goyal <7895pulkit@gmail.com> [Tue, 20 Jun 2017 23:50:50 +0530] rev 32989
py3: make sure the commands name are bytes in test-devel-warnings.t
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 20 Jun 2017 23:46:18 +0530] rev 32988
py3: replace str with bytes in isinstance()
We were using str because on Python 2, str were bytes but now we have to use
bytes. Otherwise the if conditions fails and we have weird results from commands
on Python 3.
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 20 Jun 2017 22:11:46 +0530] rev 32987
py3: catch binascii.Error raised from binascii.unhexlify
Before Python 3, binsacii.unhexlify used to raise TypeError, now it raises
binascii.Error.
Jun Wu <quark@fb.com> [Tue, 20 Jun 2017 23:39:59 -0700] rev 32986
shelve: allow unlimited shelved changes per name
Previously, there is a 100 changes limit per name (bookmark or named
branch). And the user will get "too many shelved changes named %s" when they
are trying to shelve the 101th change. I hit that error message today.
This limit was introduced by the shelve extension since the beginning.
The function generating the names was called "gennames", under
"getshelvename".
There is another "gennames" under "backupfilename":
def backupfilename(self):
def gennames(base):
yield base
base, ext = base.rsplit('.', 1)
for i in itertools.count(1):
yield '%s-%d.%s' % (base, i, ext)
"itertools.count" is an endless counter.
Since the other "gennames" generates unlimited number of names, and the
changeset introducing the limit (49d4919d21) does not say why the limit
is useful. It seems safe to just remove the limit.
The format "%02d" was kept intentionally so existing shelved changes won't
break.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:51:37 +0200] rev 32985
config: use the new '_unset' value for 'configsuboptions'
This should let configsuboptions delegate all special processing of the default
config value to the main 'config' method.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 18:28:20 +0200] rev 32984
config: use the 'config' method in 'configsuboptions'
There was unnecessary code duplication. It was getting in the way of the
unification of the default value logic.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:52:02 +0200] rev 32983
config: use the new '_unset' value for 'configpath'
This should let 'configpath' delegate all special processing of the default
config value to the main 'config' method.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:54:45 +0200] rev 32982
config: use the new '_unset' value for 'configdate'
This should let 'configdate' delegate all special processing of the default
config value to the main 'config' method.
The default value for date (None) is still enforced in this method if no other
default were passed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:54:04 +0200] rev 32981
config: use the new '_unset' value for 'configlist'
This should let 'configlist' delegate all special processing of the default
config value to the main 'config' method.
The default config value ([]) is still handled in this method.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:53:51 +0200] rev 32980
config: use the new '_unset' value for 'configbytes'
This should let 'configbytes' delegates all special processing of the default
config value to the main 'config' method.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:53:40 +0200] rev 32979
config: use the new '_unset' value for 'configint'
This should let 'configint' delegates all special processing of the default
config value to the main 'config' method.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:52:31 +0200] rev 32978
config: use the new '_unset' value for 'configwith'
This should let 'configwith' delegate all special processing of the default
config value to the main 'config' method.
This changeset introduce a small change in behavior since the default value is
run through the 'convert' function. This does not seems harmful and no actual
test break. This small change make the code simpler so I'm keeping it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:52:16 +0200] rev 32977
config: use the new '_unset' value for 'configbool'
This should let 'configbool' delegate all special processing of the default
config value to the main 'config' method.
The default value for bool (False) is still enforced in this method if no other
default were passed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:51:11 +0200] rev 32976
config: explicitly track the use of the standard default value
We introduce a small object used to detect that no specific default value has
been passed to 'ui.config'. We need this explicit special value since "None" is
a valid and common default value.
The end goal here is to make progress on a centralised and explicit declaration
of the available config option. A first good usecase for this are "default"
value. Before starting looking further down this alley we needs to rework the
handling of default value in the 'ui' object to have all configxyz methods going
through the same logic. This is the first changeset on this trek.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 22:14:37 -0700] rev 32975
clonebundle: update hook arguments (BC)
By calling applybundle() with 'clonebundles' and the url instead of
calling processbundle(), the hooks will get different arguments:
HG_SOURCE will be 'clonebundles' instead of 'bundle2' and HG_URL will
be the url instead of 'bundle2'. This is consistent with the bundle1
behavior and seems like a bug fix, but I'm marking it BC anyway.
Sean Farley <sean@farley.io> [Sat, 10 Jun 2017 23:42:38 -0700] rev 32974
commands: move checkconflict to bookmarks module
Again, commands.bookmark is getting too large. checkconflict already has
a lot of state and putting it in the bmstore makes more sense than
having it as a closure. This also allows extensions a place to override
this behavior.
While we're here, add a documentation string because, well, we should be
documenting more of our methods.