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.
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.
