This works around a potential issue in Python 2.4 where cloning a repo
with a URL like http://foo:8080 would cause urllib2 to query on
http://foo:8080?cmd=capabilities instead of
http://foo:8080/?cmd=capabilities.
In the past, this issue has been masked by the fact that
url.getauthinfo() added a trailing slash when it was missing.
Pull outputs a slightly new message when there are multiple branches and
the current branch has many heads:
(run 'hg heads .' to see heads, 'hg merge' to merge)
This message adds the "." in hg heads to encourage you to consider only the
current branch's heads.
After a pull when new heads are added but no head is added on the current
branch, the "run 'hg merge'" message can be misleading. This patch doesn't
output the merge message in that scenario.
"mtn automate stdio" will break output larger than 32kB into several packets.
This ensures that we are processing all the output on the main stream and not
only the last packet.
Monotone treats branch closing ("suspending") in a similar manner to how we do
in mercurial - a cert is added to a revision that marks the branch to be hidden.
If a subsequent commit is made, the branch is effectively reopened.
This adds a url object that re-implements urlsplit() and
unsplit(). The implementation splits out usernames, passwords, and
ports.
The implementation is based on the behavior specified by RFC
2396[1]. However, it is much more forgiving than the RFC's
specification; it places no specific restrictions on what characters
are allowed in each segment of the URL other than what is necessary to
split the URL into its constituent parts.
[1]: http://www.ietf.org/rfc/rfc2396.txt
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.
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.
# 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...
- fix bug in replacebyte: parameter fn wasn't used (no harm done)
- remove unneeded matcher
- remove unused local n
- increase test coverage a bit with a second file and some sleeping
- show files changed in revisions
- move print statements out of racy path to make sure it's as racy as possible
Immediately sends local's heads to the server to check whether the server knows them all.
If it does, we can call getbundle immediately.
Interesting test output changes are:
- added 1 changesets with 0 changes to 1 files (+1 heads)
+ added 1 changesets with 0 changes to 0 files (+1 heads)
-> The new getbundle() actually fixes a bug vs. changegroupsubset() in that it no longer
returns unnecessary files when file revs are reused.
warning: repository is unrelated
+ requesting all changes
-> The new use of common instead of bases correctly indicates that an unrelated pull
gets all changes from the server.
getbundle(common, heads) -> bundle
Returns the changegroup for all ancestors of heads which are not ancestors of common. For both
sets, the heads are included in the set.
Intended to eventually supercede changegroupsubset and changegroup. Uses heads of common region
to exclude unwanted changesets instead of bases of desired region, which is more useful and
easier to implement.
Designed to be extensible with new optional arguments (which will have to be guarded by
corresponding capabilities).
So far we've been denying rebasing descendants onto ancestors, but there are
situations in which this kind of operation makes perfect sense to me.
Let's say we have made a commit (or more), that belongs to branch 'dev', on
top of the named branch 'stable':
... a (stable) - b (dev)
but then we realize that b should belong to branch 'stable'.
In these cases a rebase means: "move these csets from named branch A to named
branch B" and there isn't a valid reason to deny it.
This patch basically doesn't block it, if source and destination are
on different named branches.
The old behaviour still applies for rebases across the same named branch.
Can you think of any tricky corner cases in which this new behaviour could
lead to problems? (I bet there are tons of them...)
By the way, I created a brand new .t because I feel there should be more
tests I can't think of at the moment.
known([Node]) -> [1/0]
Returns 1/0 for each node, indicating whether it's known by the server.
Needed for new discovery protocols introduced in later patches.
(issue2264, issue2516)
The race happens when two commits in a row change the same file
without changing its size, *if* those two commits happen in the same
second in the same process while holding the same repo lock. For
example:
commit 1:
M a
M b
commit 2: # same process, same second, same repo lock
M b # modify b without changing its size
M c
This first manifested in transplant, which is the most common way to
do multiple commits in the same process. But it can manifest in any
script or extension that does multiple commits under the same repo
lock. (Thus, the test script tests both transplant and a custom script.)
The problem was that dirstate.status() failed to notice the change to
b when localrepo is about to do the second commit, meaning that change
gets left in the working directory. In the context of transplant, that
means either a crash ("RuntimeError: nothing committed after
transplant") or a silently inaccurate transplant, depending on whether
any other files were modified by the second transplanted changeset.
The fix is to make status() work a little harder when we have
previously marked files as clean (state 'normal') in the same process.
Specifically, dirstate.normal() adds files to self._lastnormal, and
other state-changing methods remove them. Then dirstate.status() puts
any files in self._lastnormal into state 'lookup', which will make
localrepository.status() read file contents to see if it has really
changed. So we pay a small performance penalty for the second (and
subsequent) commits in the same process, without affecting the common
case. Anything that does lots of status updates and checks in the
same process could suffer a performance hit.
Incidentally, there is a simpler fix: call dirstate.normallookup() on
every file updated by commit() at the end of the commit. The trouble
with that solution is that it imposes a performance penalty on the
common case: it means the next status-dependent hg command after every
"hg commit" will be a little bit slower. The patch here is more
complex, but only affects performance for the uncommon case.
This is a simple patch to make hg push/hg outgoing print their remote target
path even if the operation fails. I'm not sure if the original behavior was by
design.
This patch also changes one test to reflect the changed behaviour.
We check if the current bookmark is set to the first parent of the
dirstate. Is this the case we move the bookmark to most recent revision
on the current branch (where hg update will update you to).
We want to update the current bookmark to the most recent revision on
current branch unless there is a remote bookmark that points to
a different descendant. Addchangegroup is called before we can check for
remote bookmarks.
We don't update the bookmark in addchangegroup anymore to allow proper updating
of bookmarks in pull.
When collapsing changesets with rebase, you get a chance to edit the commit
message manually, but there is no way to pass this message from the command
line. This patch adds a `--message` (with short form `-m`) and `--logfile`
(with short form `-m`) options to the rebase command. These options suppresses
the generation of the default commit message, and instead use the message
provided in the option (in case of `-m`) or in the file it points to (in case
of `-l`).
If you use this option without the `--collapse` option, it will raise an
error.
Options documentation edited by Patrick Mezard <pmezard@gmail.com>
