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
The commit editor is now invoked before files and manifest are
committed. The editor is now run with only the wlock held and aborting
an edit no longer requires rolling back a transaction. Changes to
files during a commit still result in undefined behavior.
(This is preliminary work for committing subrepositories)
This adds a change to the way that abort is processed, as it will not continue
truncating files beyond the first failure, otherwise the respective
functionality is maintained, i.e. abort will not unlink files, but rollback
will.
Co-contributor: Sune Foldager <cryo@cyanite.org>
all locks should use the explicit lock.release
mercurial.lock.lock.__del__ handles unwrapping recursive locks
localrepo.lock/wlock are still using weakref in order to keep backward
compatibiltiy to releasing locks via garbage collection
by ensuring the release on __del__
Solves that committed (closed) transactions may linger and be returned
on subsequent transaction calls, even though a new transaction should
be made, rather than a new nested transaction.
This also fixes a race condition with the use of weakref.
- add writepending to flush delayed writes to separate file
- add support in hooks for lazy evaluation of callable parameters
- add HG_PENDING to pretxn hooks
- call writepending if hook is used
- pass repo root to hook environment
- if HG_PENDING = repo root, we're in pretxn hook
- read pending data to make pending changesets visible
- filter HG_PENDING in tests/printenv.py
There was no good reason to special case the 'default' branch.
Allow the 'default' branch to be closed if the user wants it.
If you're uncomfortable about mistakenly closing the default branch,
you can always reopen the branch by commiting a "normal" changeset onto
the closed branch.
The issue came from the 63f9ab8034d1 fix for issue586 working only for
manifest.add() fast path, where the incorrect removed file set was
ignored. This path was no longer taken after 5958346d119e refactoring.
Treat fully closed branches similarly to "inactive" in the output of
'hg branches'. They will be suffixed with "(closed)" where inactive branches
are marked with "(inactive)". If the -a/--active option is given both
inactive and closed branches will not be shown.
Partially closed branches (multiple heads, at least one not closed)
will display the next (tipmost) open head.
Add -a/--active option to "hg heads" which will hide closed heads iff the
option is specified.
In other hg commands, when multiple branch heads exist the branch name will
refer to the tipmost open head, and if none exist, then the tipmost closed
head.
Adds a --close-branch option to commit.
When --close-branch is present the commit will mark the changeset
with close=1 in the changeset extras field.
If a regular changeset is added on top of a closed head the branch
is no longer considered closed, and thus re-opened.
All heads of branches will be stored in a new cache file 'branchheads.cache'
within the .hg directory. The old 'branch.cache' file from older versions
will be ignored.
The new cache contents are formatted line-by-line as '{node} {branchtag}\n'.
This is the same as the previous format. Now, every head is recorded in
an oldest -> tipmost order.
The localrepo.branchheads function is reworked to use the data from the cache.
- create error.py for exception classes to reduce demandloading
- move revlog exceptions to it
- change users to import error and drop revlog import if possible
This should be faster and more future-proof. Calls where the result is to be
sorted using util.sort() have been left unchanged. Calls to .items() on
configparser objects have been left as-is, too.
