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.
This patch stops mercurial from pushing unmodified subrepos. An unmodified
subrepo is one whose store is "clean" versus a given target subrepo.
Note that subrepos may have a clean store versus a target repo but not versus another. This patch handles this scenario by individually keeping track of the state of the store versus all push targets.
Tests will be added on the following revision.
The mercurial subrepo "storeclean" method works by calculating a "store hash" of
the repository state and comparing it to a cached store hash. The store hash is
always cached when the repository is cloned from or pushed to a remote
repository, but also on pull as long as the repository already had a clean
store. If the hashes match the store is "clean" versus the selected repository.
Note that this method is currenty unused, but it will be used by a later patch.
The store hash is calculated by hashing several key repository files, such as
the bookmarks file the phaseroots file and the changelog. Note that the hash
comparison is done file by file so that we can exit early if a pair of hashes
do not match. Also the hashes are calculated starting with the file that is
most likely to be smaller upto the file that is more likely to be larger.
Currently this method is unused and it is not implemented for any specific
subrepo type (it always returns False). It receives a remote repository path
because a repository may have a clean store versus a given repository but not
versus another.
These names were found using Cython; I was completely puzzled until
I searched the rest of the tree. It's icky to mess with another
module's namespace, but ickier yet to do so without a comment :-)
This prevents us from having a bunch of errant worker processes all try
to release a lock if a problem occurs. (Releasing the lock more than once
is harmless; it's invoking the associated callbacks we want to avoid.)
Obsolescence creates a sparse DAG mostly composed of a lot of small independent
chain of markers. Date is the only simple and "reliable" way to sort them. The
existence of a date is now enforced at creation time as I'm more and more
convinced that date will have a key role in obsolescence markers exchange.
Use `debuglabelcomplete` command when populating labels list, instead of
calling `hg` three times: for branches, bookmarks and tags. Do not pass string
being completed to `hg debuglabelcomplete` (as `$words[$CURRENT]`), since it
breaks `_hg_revrange` completion (`--rev 2.5:2.5.<Tab>`) for no apparent
benefit.
Also complete `hg view` with labels, not just tags, and drop unused `_hg_tags`.
perfdirs results for a working dir with 170,000 files:
Python 638 msec
C 244
C+int 192
C+int+str 168
In the large repo above, the nearly 0.5 second time improvement is
visible in commands like "hg add" and "hg update".
hg add
Python 1100 msec
C+int+str 600
hg update (with nothing to do)
Python 2800 msec
C+int+str 2240
This is over twice as fast as the Python dirs code. Upcoming changes
will nearly double its speed again.
perfdirs results for a working dir with 170,000 files:
Python 638 msec
C 244
This encapsulates the "multiset of directories" structures that are
currently open-coded (and duplicated) in both the dirstate and
context modules.
This will be used, and optionally replaced by a C implementation,
in upcoming changes.
This can happen when a file with flags is removed or deleted in the working
directory and also not present in m2. The obvious solution is to add a
__delitem__ override to manifestdict that removes the file from flags if
necessary, but that has a significant performance cost in some cases, e.g.
hg status --rev rev1 --rev rev2 <file>.
