Mon, 15 Apr 2013 01:22:15 +0900 localrepo: use vfs instead of "os.path.*" in sharedpath checking
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 15 Apr 2013 01:22:15 +0900] rev 18946
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.
Mon, 15 Apr 2013 01:22:15 +0900 vfs: split "expand" into "realpath"/"expandpath" to apply each separately
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 15 Apr 2013 01:22:15 +0900] rev 18945
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.
Fri, 18 Jan 2013 15:54:09 +0100 unionrepo: read-only operations on a union of two localrepos
Mads Kiilerich <madski@unity3d.com> [Fri, 18 Jan 2013 15:54:09 +0100] rev 18944
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip