Some extensions (e.g. hgsubversion) completely override push command. Because
extensions load order is unspecified, if hgsubversion loads before mq, mq
checks about not pushing applied patches will be bypassed. Short of finding a
way to fix load order, extracting the checking logic will allow
hgsubversion-like extensions to run the check themselves.
The generation of cache files like tags.cache and branchheads.cache is not an
actual reflection of things changing in the whole of the .hg directory (like eg
a commit or a rebase or something) but instead these cache files are just part
of bookkeeping. As such its convienant to allow various clients to ignore file
events to do with these cache files which would otherwise cause a double
refresh. Eg one refresh might occur after a commit, but the act of refreshing
after the commit would cause Mercurial to generate a new branchheads.cache which
would then cause a second refresh, for clients.
However if these cache files are moved into a directory like eg .hg/cache/ then
GUI clients on OSX (and possibly other platforms) can happily ignore file events
in this cache directory.
These leaks may occur in environments that don't employ a reference
counting GC, i.e. PyPy.
This implies:
- changing opener(...).read() calls to opener.read(...)
- changing opener(...).write() calls to opener.write(...)
- changing open(...).read(...) to util.readfile(...)
- changing open(...).write(...) to util.writefile(...)
This speeds up the in-memory version of debugbuilddag that I'm
working on considerably for the case where we want to build just
a 00changelog.i (for discovery tests, for instance).
There are a couple of test changes because node ids in tests
have changed.
The changes to the patch names in test-mq-qdelete.t were required
because they could collide with nodeid abbreviations and newly
actually do (patch "c" collides with id "cafe..." for patch "b").
All tests repeatedly passes with a3900c75ca8c on some machines, but on other
machines it regularly causes failure in test-mv-cp-st-diff.t, such as:
@@ -203,6 +203,7 @@
- working to root: --rev 0
M a
+ M x/x
A b
a
The introduction of the new URL parsing code has created a startup
time regression. This is mainly due to the use of url.hasscheme() in
the ui class. It ends up importing many libraries that the url module
requires.
This fix helps marginally, but if we can get rid of the urllib import
in the URL parser all together, startup time will go back to normal.
perfstartup time before the URL refactoring (707e4b1e8064):
! wall 0.050692 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
current startup time (9ad1dce9e7f4):
! wall 0.070685 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
after this change:
! wall 0.064667 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
This is a long desired cleanup and paves the way for new discovery.
To specify subsets for bundling changes, all code should use the heads
of the desired subset ("heads") and the heads of the common subset
("common") to be excluded from the bundled set. These can be used
revlog.findmissing instead of revlog.nodesbetween.
This fixes an actual bug exposed by the change in test-bundle-r.t
where we try to bundle a changeset while specifying that said changeset
is to be assumed already present in the target. This used to still
bundle the changeset. It no longer does. This is similar to the bugs
fixed by the recent switch to heads/common for incoming/pull.
Updating the branch cache is quadratic to the amount of heads in the
repository. One consequence of this was that cloning a pathological
repository with 10,000 heads (and nothing else) took hours of CPU
time.
This patch makes one of the inner loop much faster, by removing a
changectx instantiation, and removes another entirely in cases where
there are no candidate branch heads which descend from other branch
heads.
New argument is silently ignored by both HTTP and SSH servers.
This means we can, for instance, add new flags to getbundle()
to request advanced features (like lightweight-copy-aware bundles),
and older servers will silently ignore this request and send back
a plain bundle.
If a closed head gets pulled, we currently see (example):
$ hg pull
pulling from $TESTTMP/repo2
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
A subsequent 'hg heads' doesn't show that head because it is closed.
This patch improves the UI response texts for that same use case to:
$ hg pull
pulling from $TESTTMP/repo2
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
That is, the part "(+1 heads)" is not shown in that case any longer.
If a file is deleted (rm, not 'hg rm') from the working dir
an attempt to run 'hg diff -r X', with the file being present in X will
cause an abort.
We didn't check if the file has been deleted from the working dir
and later on tried to open it to compare with the one from X, causing the abort.
This fix adds that check. Consequently, no output will be returned.
The manifest value of a file will never be false when "not parentworking", and
the expensive content comparision would thus fortunately never be reached. (If
it was reached it would be wrong for example in case of renames.)
This code once handled status against working directory, but that has been done
elsewhere for a long time.
This replaces util.drop_scheme() with url.localpath(), using url.url for
parsing instead of doing it on its own. The function is moved from
util to url to avoid an import cycle.
hg.localpath() is removed in favor of using url.localpath(). This
provides more consistent behavior between "hg clone" and other
commands.
To preserve backwards compatibility, URLs like bundle://../foo still
refer to ../foo, not /foo.
If a URL contains a scheme, percent-encoded entities are decoded. When
there's no scheme, all characters are left untouched.
Comparison of old and new behaviors:
URL drop_scheme() hg.localpath() url.localpath()
=== ============= ============== ===============
file://foo/foo /foo foo/foo /foo
file://localhost:80/foo /foo localhost:80/foo /foo
file://localhost:/foo /foo localhost:/foo /foo
file://localhost/foo /foo /foo /foo
file:///foo /foo /foo /foo
file://foo (empty string) foo /
file:/foo /foo /foo /foo
file:foo foo foo foo
file:foo%23bar foo%23bar foo%23bar foo#bar
foo%23bar foo%23bar foo%23bar foo%23bar
/foo /foo /foo /foo
Windows-related paths on Windows:
URL drop_scheme() hg.localpath() url.localpath()
=== ============= ============== ===============
file:///C:/foo C:/C:/foo /C:/foo C:/foo
file:///D:/foo C:/D:/foo /D:/foo D:/foo
file://C:/foo C:/foo C:/foo C:/foo
file://D:/foo C:/foo D:/foo D:/foo
file:////foo/bar //foo/bar //foo/bar //foo/bar
//foo/bar //foo/bar //foo/bar //foo/bar
\\foo\bar //foo/bar //foo/bar \\foo\bar
Windows-related paths on other platforms:
file:///C:/foo C:/C:/foo /C:/foo C:/foo
file:///D:/foo C:/D:/foo /D:/foo D:/foo
file://C:/foo C:/foo C:/foo C:/foo
file://D:/foo C:/foo D:/foo D:/foo
file:////foo/bar //foo/bar //foo/bar //foo/bar
//foo/bar //foo/bar //foo/bar //foo/bar
\\foo\bar //foo/bar //foo/bar \\foo\bar
For more information about file:// URL handling, see:
http://www-archive.mozilla.org/quality/networking/testing/filetests.html
Related issues:
- issue1153: File URIs aren't handled correctly in windows
This patch should preserve the fix implemented in
5c92d05b064e. However, it goes a step further and "promotes"
Windows-style drive letters from being interpreted as host names to
being part of the path.
- issue2154: Cannot escape '#' in Mercurial URLs (#1172 in THG)
The fragment is still interpreted as a revision or a branch, even in
paths to bundles. However, when file: is used, percent-encoded
entities are decoded, so file:test%23bundle.hg can refer to
test#bundle.hg ond isk.
split can be more readable for longer lists like the list in
dirstate.invalidate. As dirstate.invalidate is used in wlock() and therefoe
used heavily, I think it's worth avoiding a split there too.
This patch avoids empty commit when .hgsubstate is dirty. Empty commit
was caused by .hgsubstate being updated back to the state of the
working copy parent when committing, if a user had changed it manually
and not made any changes in subrepositories.
The subrepository state from the working copies parent is compared
with the state calculated as a result of trying to commit the
subrepositories. If the two states are the same, then return None
otherwise the commit is just done.
The line: "committing subrepository x" will be written if there is
nothing committed, but .hgsubstate is dirty for x subrepository.
This uses the same strategy as progress for pulls, estimating manifests
based on changeset count and estimating file count by files list in
each changeset.
The opener already unlinks the filename before 'w'riting, for both
the symlink and the normal file case. It also now resets the flags
for normal files on 'w'rite, which makes this os.unlink call completely
redundant.
For Windows, removing this extra unlink call helps to avoid tripping
issue2524 (os.unlink followed by a write).
Previously, branch names were ideally manipulated as UTF-8 strings,
because they were stored as UTF-8 in the dirstate and the changelog
and could not be safely converted to the local encoding and back.
However, only about 80% of branch name code was actually using the
right encoding conventions. This patch uses the localstr addition to
allow working on branch names as local strings, which simplifies
handling so that the previously incorrect code becomes correct.
When issuing `hg pull -r REV` in a repo with no common ancestor with the
remote repo, the message 'requesting all changes' is printed, even though only
the changese that are ancestors of REV are actually requested. This can be
confusing for users (see
http://www.selenic.com/pipermail/mercurial/2010-October/035508.html).
This silences the message if (and only if) the '-r' option was passed.
- Mac OS X has problems with filenames starting with '._'
(e.g. '.FOO' -> '._f_o_o' is now encoded as '~2e_f_o_o')
- Explorer of Windows Vista and Windows 7 strip leading spaces of
path elements of filenames when copying trees
Above problems are avoided by encoding the first space (as '~20') or
period (as '~2e') of all path elements.
This introduces a new entry 'dotencode' in .hg/requires, that is,
a new repository filename layout (inside .hg/store).
Newly created repositories require 'dotencode' by default. Specifying
[format]
dotencode = False
in a config file will use the old format instead.
Prior Mercurial versions will abort with the message
abort: requirement 'dotencode' not supported!
when trying to access a local repository that requires 'dotencode'.
New 'dotencode' repositories can be converted to the previous
repository format with
hg --config format.dotencode=0 clone --pull repoA repoB
This patch fixes issues with stream cloning in the presense of parentdelta,
lwcopy and similar additions that change the interpretation of the revlog
format, or the format itself.
Currently, the stream capability is sent like this:
stream=<version of changelog>
But the client doesn't actually check the version number; also, it only checks
the changelog and it doesn't capture the interpretation-changes and
flag-changes in parentdelta and lwcopy.
This patch removes the 'stream' capability whenever we use a non-basic revlog
format, to prevent old clients from receiving incorrect data. In those cases,
a new capability called 'streamreqs' is added instead. Instead of a revlog
version, it comes with a list of revlog-format relevant requirements, which
are a subset of the repository requirements, excluding things that are not
relevant for stream.
New clients use this to determine whether or not they can stream. Old clients
only look for the 'stream' capability, as always. New servers will still send
this when serving old repositories.
Currently, localrepo.branchtags() is called in two locations to update the
_branchcache dict, however branchtags() itself does not update anything, it
calls branchmap() to do so. This change introduces a new updatebranchcache()
method that is used by both branchmap() and the calls to update the cache.
This method was introduced by b0e5c3bce42a but grepping the history does not
reveal any call. Extensions may use it but the method intent is not even clear
to me.
Separate loading part from access part to be able to tell with:
repo._loadfilter(name)
bool(name in repo.filterpats)
if there is a 'name' filter available.
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).
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.
Ancestors of nodes linked to commonrevs can be expected to be linked
to commonrevs. Walking graphs of each revlog looking for rare/nonexistent outliers is overkill.
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.
We explicitly want to update bookmarks from a remote. This will avoid
duplicate calls to listkeys if we clone (which calls pull) and keep
bookmark related code together.
Currently, callers of addchangegroup first acquire the repository
lock, usually to check that an unbundle request isn't racing. This
means that changegroup hook actions that might write to a repo get
stuck waiting for a lock. Here, we add a new optional lock parameter
and update all the callers. Post-1.6 we may make it non-optional.
Compare this to --force which allows anything to be pushed. With --new-branch,
only changesets to named branches not present on the and changesets not
introducing additional heads on existing branches are allowed.
Developed by
Henrik Stuart <henrik.stuart@edlund.dk>
Sune Foldager <cryo@cyanite.org>
bisect: clarify None return
bundle: return 1 on no changes
clone: return result code
copy: limit errors to 0/1
commit: return 1 on no changes
forget: return 1 on errors
grep: return 1 if no match found
remove: return 1 on errors
resolve: return 1 if something fails to resolve
rollback: return 1 if no rollback data
This starts at localrepository.push() and seeps down to
push_addchangegroup(), push_unbundle(), prepush(), addchangegroup(),
and leaks out to sshrepository.unbundle(), sshrepository.addchangegroup(),
and httprepository.unbundle(). Seems to cover everything you ever
wanted to know about pushing but were afraid to ask.
This makes more sense when using multiple levels of
nesting.
This happens to help a lot in a case where 3 projects
of mine all use the same makefile helper project as a
sub. A fourth project use these first three projects
and current output made it very hard to figure
which makefile helper was committed. it looked more
like the project was committed/pushed/pulled three times
in a row than dealing on three different repos.
As reported recently, Mercurial users can easily find confusion when
using a common name for a tag and a branch. It seems reasonable to warn
them about this potential outcome, to avoid that "surprise".
* Explain briefly the issue in "hg help tag"
* Warn when tagging a revision
Fixes issue2078 and adds tests to cover various 'hg log -b' uses.
This change adds a localrepo.lookupbranch(key, remote=None) function. This
will look up the branch of the revision with the given key. The algorithm
works like this:
* If a remote repo is given and KEY is the name of a branch in that repo,
return KEY.
* If no remote repo is given and KEY is the name of a branch in the local
repo object, return KEY.
* Otherwise look up the revision with the identifier KEY in the local repo
and return its branch.
This change also makes 'hg log -b' use this new functionality and adds a few
tests for it.
For servers with branchmap support, the algorithm now works as follows:
1. A list of branches in outgoing changesets is created.
2. Using the remote branchmap, a check for new branches is performed.
3. A map (from branch to head list) of locally known remote heads before
the push is created, and one which, after step 4, will contain the locally
known remote heads after the push.
4. The post-push head map is updated with the outgoing changesets, using the
branch cache update mechanism.
5. A check for new heads is performed, by comparing the length of the head list
before and after push, for each branch. If there are new heads, an error
depending on whether or not there are incoming changes on the branch,
is returned.
6. If the push is allowed, a warning is written if there are incoming changes
on any branches involved in the push.
For old servers, an algorithm similar to step 4-6 above is used to check for
new topological heads only.
Two bugs are also fixed:
1. Sometimes you would be allowed to push new branch heads without --force.
A test for this case was added.
2. You would get the "note: unsynced remote changes!" warning if there were any
incoming changesets, even if they were on unrelated branches.
All callers to localrepo.transaction() must supply a transaction description.
The description and the existing repository tip are then stored
(transactionally) into .hg/undo.desc; where rollback can later find it.
Simplifies the prepush check logic and makes it a lot more direct and
comprehensible. Instead of comparing the total local vs. remote head count, it
compares the number of new vs. removed heads.
When a subrepo is deleted from .hgsub, it also needs to be removed from
.hgsubstate. Previous code was updating .hgsubstate only in case of newly or
modified subrepo.
This avoids problem with unexpanded paths when it's not possible to
expand it at higher level (for example, if file:~/path/ is supplied as
path in schemes).
The IOError exception is overloaded to mean 'this file was deleted in
the current commit'. Separate the code that handles IOError and file
deletion from general OSError exceptions. The latter are real errors,
but IOError is not always a throwable error.
This solves the accidental marking of files as 'deleted' in commits that
try to write for example in .hg/store/data revlogs that the current user
has no permission to modify (a normal OSError that should abort the
current commit).
Changed by pmezard: use getattr() to be on the safe side.
This verifies that all manifests are present for incoming changes,
and all files for those manifests are also present. This is a simple
first-pass, and could be better, but seems like a valuable thing to
have, as I've seen pushes in the past that propagated revlog corruption.
Part of the patch is from timeless@mozdev.org
- indicate the branch name where there are multiple heads
- give better advice when hitting a possible race, where new heads are added
between discovery and the call to branchmap(). In that case, asking the user
to merge isn't helpful, since only remote has the changes.
When creating new branches and merging them into existing ones, you would
sometimes be able to push some changesets (the existing branches) without using
--force, even when that creates a new head on the remote.
A test which triggers the error has been added.
The fast path in changegroupsubset can send too many csets. This happens
because it uses the parents of all bases as common nodes and then goes
forward from this again. If a base has a parent that has another child,
which is -not- a base, then this other child will nevertheless end up in
the changegroup.
The fix is to not use findmissing(), but use nodesbetween() instead, as
do the slow path and incoming/outgoing.
The change to test-notify.out is correct, because it actually hits this
bug, as can be seen by glog'ing the two repos:
@ 22c88
|\
| o 0a184
| |
o | 0647d
|/
o cb9a9
and
o 0647d
|
@ cb9a9
It used to pull 0647d again, which is unnecessary.
Journal already exists is a pretty internal piece of information, which
doesn't necessarily mean much to people who are not familiar with the code.
The new text is a more well-known concept.
The previous branch heads cache implementation iterated all ancestors
for each new revision in the repository, causing a massive slowdown on
cloning larger repositories.
For merge nodes it is not adequate to only check a single possible
branch head for whether it is an ancestor of the latest head, but it
needs to be done for each possible branch head.
- modify _readtagcache() and _writetagcache() to read/write tag->node
mapping for global tags
- if (and only if) tip unchanged, use that cached mapping to avoid
reading any revisions of .hgtags
- change so tag names are UTF-8 in memory in tags.py, and converted to
local encoding as late as possible (in localrepository._findtags())
- rename findglobaltags() to findglobaltags1() (so the "no cache"
implementation is still there if we need it)
- add findglobaltags2() and make findglobaltags() an alias for it
(disabling tag caching is a one-line patch)
- factor out tagcache class with methods readcache() and writecache();
the expensive part of tag finding (iterate over heads and find
.hgtags filenode) is now in tagcache.readcache()
- rename many local variables
- add some comments
- refactor call to line.split() (catch ValueError rather
than checking length of return value: one less local variable)
- self.tagscache to self._tags
- self._tagstypecache to self._tagtypes
- this is for consistency, readability, privacy, and to subtly hint
that "caching" is something else
For example, given 1 (branch a) -> 2 (branch b) -> 3 (branch a)
I expect "hg heads a" to show only 3.
Discovered by running hg heads HEAD on the mutt repo, where older clients
committed default on top of HEAD.
- repository heads are not associated with the closed attribute, so
remove it making the code in line with the concept.
- Fix functions that were calling heads with the parameter.
- Adjust webcommands.branches to include the concept of inactive
as well as open and closed branches
- Fix code and docstrings in commands to make the correct use of
closed branches & branch heads clearer
- Improve grammar of 'hg heads' help text (2nd submission)
this does not alter the cli for hg branches, that work is
still to be done
The heads(...) and branchheads(...) functions will now only return closed
heads when explicitly asked for them. This will cause 'hg merge' to have
better behavior in the presence of a branch that has closed heads when no
explicit rev is passed.
Each named branch is considered separately, and the push is allowed if
no new branch heads are created for any named branch to be pushed.
Due to some tests's use of --debug, their output will change after this
addition. This has been fixed as well.
Co-contributor: Henrik Stuart <henrik.stuart@edlund.dk>
The repository command, 'branchmap', returns a dictionary, branchname
-> [branchheads], and will be implemented for localrepo, httprepo and
sshrepo.
The following wire format is used for returning data:
branchname1 branch1head2 branch1head2 ...
branchname2 ...
...
Branch names are URL encoded to escape white space, and branch heads
are sent as hex encoded node ids. All branches and all their heads are
sent.
The background and motivation for this command is the desire for a
richer named branch semantics when pushing changesets. The details are
explained in the original proposal which is included below.
1. BACKGROUND
The algorithm currently implemented in Mercurial only considers the
graph theoretical heads when determining whether new heads are
created, rather than using the branch heads as a count (the algorithm
considers a branch head effectively closed when it is merged into
another branch or a new named branch is started from that point
onward).
Our particular problem with the algorithm is that we'd like to see the
following case working without forcing a push:
Upsteam has:
(0:dev) ---- (1:dev)
\
`--- (2:stable)
Someone merges stable into dev:
(0:dev) ---- (1:dev) ------(3:dev)
\ /
`--- (2:stable) --------´
This can be pushed without --force (as it should).
Now someone else does some coding on stable (a bug fix, say):
(0:dev) ---- (1:dev) ------(3:dev)
\ /
`--- (2:stable) ---------´---------(4:stable)
This time we need --force to push.
We allow this to be pushed without using --force by getting all the
remote branch heads (by extending the wire protocol with a new
function).
We would, furthermore, also prefer if it is impossible to push a new
branch without --force (or a later --newbranch option so --force isn't
shoe-horned into too many disparate functions, if need be), except of
course in the case where the remote repository is empty.
This is what our patches accomplish.
2. ALTERNATIVES
We have, of course, considered some alternatives to reconstructing
enough information to decide whether we are creating new remote branch
heads, before we added the new wire protocol command.
2.1. LOOKUP ON REMOTE
The main alternative is to use the information from remote.heads() and
remote.lookup() to try to reconstruct enough graph information to
decide whether we are creating new heads. This is not adequate as
illustrated below.
Remember that each lookup is typically a request-response pair over
SSH or HTTP(S).
If we have a simple repository at the remote end like this:
(0:dev) ---- (1:dev) ---- (3:stable)
\
`--- (2:dev)
then remote.heads() will yield [2, 3]. Assume we have nodes [0, 1, 2]
locally and want to create a new node, 4:dev, as a descendant from
(1:dev), which should be OK as 1:dev is a branch head.
If we do remote.lookup('dev') we will get [2]. Thus, we can get
information about whether a branch exists on the remote server or not,
but this does not solve our problem of figuring out whether we are
creating new heads or not.
Pushing 4:dev ought to be OK, since after the push, we still only have
two heads on branch a.
Using remote.lookup() and remote.heads() is thus not adequate to
consistently decide whether we are creating new remote heads (e.g. in
this situation the latter would never return 1:dev).
2.2. USING INCOMING TO RECONSTRUCT THE GRAPH
An alternative would be to use information equivalent to hg incoming
to get the full remote graph in addition to the local graph.
To do this, we would have to get a changegroup(subset) bundle
representing the remote end (which may be a substantial amount of
data), getting the branch heads from an instantiated bundlerepository,
deleting the bundle, and finally, we can compute the prepush logic.
While this is backwards compatible, it will cause a possibly
substantial slowdown of the push command as it first needs to pull in
all changes.
3. FURTHER ARGUMENTS IN FAVOUR OF THE BRANCHMAP WIRE-PROTOCOL EXTENSION
Currently, the commands incoming and pull, work based on the tip of a
given branch if used with "-r branchname", making it hard to get all
revisions of a certain branch only (if it has multiple heads). This
can be solved by requesting the remote's branchheads and letting the
revisions to be used with the command be these heads. This can be done
by extending the commands with a new option, e.g.:
hg pull -b branchname
which will be turned into the equivalent of:
hg pull -r branchhead1 -r branchhead2 -r branchhead3
We have a simple follow-up patch that can do this ready as well
(although not submitted yet as it is pending the acceptance of the
branch patch).
4. WRAP-UP
We generally find that the branchmap wire protocol extension can
provide better named branch support to Mercurial. Currently, some
things, like the initial push scenario in this mail, are fairly
counter-intuitive, and the more often you have to force push, the more
it is likely you will get a lot of spurious and unnecessary merge
nodes. Also, restricting incoming and pull to all changes on a branch
rather than changes on the tip-most head would be a sensible extension
to making named branches a first class citizen in Mercurial.
Currently, named branches sometimes feel like a late-coming unwanted
step-child.
We have run it in a production environment for a while, with fewer
multiple heads occurring in our repositories and fewer confused users
as a result.
Also, it fixes the long-standing issue 736.
Co-contributor: Sune Foldager <cryo@cyanite.org>
the escaping of directories ending with .i or .d doesn't
really belong to filelog.
we put the encoding/decoding in store instead, for backwards
compat, streamclone and the fncache file format still uses the
partially encoded filenames.
The built-in None object is a singleton and it is therefore safe to
compare memory addresses with is. It is also faster, how much depends
on the object being compared. For a simple type like str I get:
| s = "foo" | s = None
----------+-----------+----------
s == None | 0.25 usec | 0.21 usec
s is None | 0.17 usec | 0.17 usec
