Matt Mackall <mpm@selenic.com> [Thu, 24 Mar 2011 15:12:51 -0500] rev 13755
ssh: fix password test
We don't support passwords in ssh URLs, and neither do some versions
of Python's urllib. Since we don't actually care much here, punt with
a glob in the test.
Adrian Buehlmann <adrian@cadifra.com> [Thu, 24 Mar 2011 18:39:54 +0100] rev 13754
dirstate: check mtime when adding to _lastnormal
- consistently use mtime as mapped to dirstate granularity (needed for
filesystems like NTFS, which have sub-second resolution)
- no need to add files with mtime < _lastnormaltime
- improve comments
Martin Geisler <mg@aragost.com> [Thu, 24 Mar 2011 18:17:49 +0100] rev 13753
subrepo: simplify hgsubrepo._get a little
Lee Cantey <lcantey@gmail.com> [Thu, 24 Mar 2011 08:51:58 -0700] rev 13752
Fix expected url to match test.
Patrick Mezard <pmezard@gmail.com> [Thu, 24 Mar 2011 10:28:29 +0100] rev 13751
patch: deprecate ui.patch / external patcher feature
Why?
- Mercurial internal patcher works correctly for regular patches and git
patches, is much faster at least on Windows and is more extensible.
- In theory, the external patcher can be used to handle exotic patch formats. I
do not know any and have not heard about any such use in years.
- Most patch programs cannot handle git format patches, which makes the API
caller to decide either to ignore ui.patch by calling patch.internalpatch()
directly, or take the risk of random failures with valid inputs.
- One thing a patch program could do Mercurial patcher cannot is applying with
--reverse. Apparently several shelve like extensions try to use that,
including passing the "reverse" option to Mercurial patcher, which has been
removed mid-2009. I never heard anybody complain about that, and would prefer
reimplementing it anyway.
And from the technical perspective:
- The external patcher makes everything harder to maintain and implement. EOL
normalization is not implemented, and I would bet file renames, if supported
by the patcher, are not correctly recorded in the dirstate.
- No tests.
How?
- Remove related documentation
- Clearly mark patch.externalpatch() as private
- Remove the debuginstall check. This deprecation request was actually
triggered by this last point. debuginstall is the only piece of code patching
without a repository. When migrating to an integrated patch() + updatedir()
call, this was really a showstopper, all workarounds were either ugly or
uselessly complicated to implement. If we do not support external patcher
anymore, the debuginstall check is not useful anymore.
- Remove patch.externalpatch() after 1.9 release.
Matt Mackall <mpm@selenic.com> [Wed, 23 Mar 2011 19:28:16 -0500] rev 13750
# User Dan Villiom Podlaski Christiansen <danchr@gmail.com>
# Date 1289564504 -3600
# Node ID b75264c15cc888cf38c3c7b8f619801e3c2589c7
# Parent 89b2e5d940f669e590096c6be70eee61c9172fff
revsets: overload the branch() revset to also take a branch name.
This should only change semantics in the specific case of a tag/branch
conflict where the tag wasn't done on the branch with the same
name. Previously, branch(whatever) would resolve to the branch of the
tag in that case, whereas now it will resolve to the branch of the
name. The previous behaviour, while documented, seemed very
counter-intuitive to me.
An alternate approach would be to introduce a new revset such as
branchname() or namedbranch(). While this would retain backwards
compatibility, the distinction between it and branch() would not be
readily apparent to users. The most intuitive behaviour would be to
have branch(x) require 'x' to be a branch name, and something like
branchof(x) or samebranch(x) do what branch(x) currently
does. Unfortunately, our backwards compatibility guarantees prevent us
from doing that.
Please note that while 'hg tag' guards against shadowing a branch, 'hg
branch' does not. Besides, even if it did, that wouldn't solve the
issue of conversions with such tags and branches...