wireproto: clarify cryptic 'remote: unsynced changes' error message on push The message was not very much to the point and did not in any way help an ordinary user. 'repository changed while preparing/uploading bundle - please try again' is more correct, gives the user some understanding of what is going on, and tells how to 'recover' from the situation. The 'bundle' aspect could be seen as an implementation detail that shouldn't be mentioned, but I think it helps giving an exact error message. The message could still leave the user wondering why Mercurial doesn't lock the repo and how unsafe it thus is. Explaining that is however too much detail.

export: export working directory parent by default A common usecase for export is to preview the patch that will be patchbombed or to see what changed in a revision found by bisect. Showing the working directory parent is thus a useful and obvious default.

commit: allow closing "non-head" changesets Backout acd61dc44a39. The changeset prevented closing non-head changesets but did not provide any rationale or test case and I don't see what value it adds. Users might have their reasons to commit something anywhere - and close it immediately. And contrary to the comment that is removed: The topo heads set is _not_ included in the branch heads set of the current branch. It do not include closed topological heads. The change thus prevented closing commits on top of closing commits. A valid usecase for that is to merge closed heads to reduce the number of topological heads. The only existing test coverage for this is the failing double close in test-revset.t. It was added in 3cc2e34d7a7d and seems to not be intentional.

record: ignore trailing content when parsing patches - introduce 'other' lines This makes record work more like import which ignores for instance mail footers in a patch file. This also makes it possible for TortoiseHg to preview unapplied patches containing such footers.

record: abort on malformed patches instead of crashing

localrepo: use "vfs.rename()" instead of "util.rename()" This patch makes "_journalfiles()" return a list of pairs of journal file and corresponded vfs instance instead of a list of journal files in full path, to use "vfs.rename()" instead of "util.rename()" in "aftertrans()". "undofiles()" still returns a list of undo files in full path, because "repair.strip()" expects such list. It'll be also made to return a list of pairs of undo file and corresponded vfs at vfs migration for "repair.strip()" in the near future.

localrepo: use "vfs.setflags()" instead of "util.setflags()"

localrepo: use "vfs.readlink()" instead of "os.readlink()"

localrepo: use "vfs.islink()" instead of "os.path.islink()"

localrepo: use "vfs.rename()" instead of "util.rename()"

localrepo: use "vfs.exists()" instead of "os.path.exists()"

localrepo: use vfs instead of "os.path.*" in sharedpath checking In the point of view of efficiency, "vfs" instance created in this patch should be passed to and reuse in "store.store()" invocation just after patched code block, because "store" object is initialized by vfs created with "self.sharedpath". eBut to focus just on migration from direct file I/O API accessing to vfs, this patch uses created vfs as temporary one. Refactoring around "store.store()" invocation will be done in the future.

vfs: split "expand" into "realpath"/"expandpath" to apply each separately Before this patch, vfs constructor applies both "util.expandpath()" and "os.path.realpath()" on "base" path, if "expand" is True. This patch splits it into "realpath" and "expandpath", to apply each functions separately: this splitting can allow to use vfs also where one of each is not needed.

unionrepo: read-only operations on a union of two localrepos unionrepo is just like bundlerepo without bundles. The implementation is very similar to bundlerepo, but I don't see any obvious way to generalize it. Some most obvious use cases for this would be log and diff across local repos, as a kind of preview of pulls, for instance: $ hg -R union:repo1+repo2 heads $ hg -R union:repo1+repo2 log -r REPO1REV -r REPO2REV $ hg -R union:repo1+repo2 log -r '::REPO1REV-::REPO2REV' $ hg -R union:repo1+repo2 log -r 'ancestor(REPO1REV,REPO2REV)' $ hg -R union:repo1+repo2 diff -r REPO1REV -r REPO2REV This is going to be used in RhodeCode, and Bitbucket already uses something similar. Having a core implementation would be beneficial.