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.
(issue2264, issue2516)
The race happens when two commits in a row change the same file
without changing its size, *if* those two commits happen in the same
second in the same process while holding the same repo lock. For
example:
commit 1:
M a
M b
commit 2: # same process, same second, same repo lock
M b # modify b without changing its size
M c
This first manifested in transplant, which is the most common way to
do multiple commits in the same process. But it can manifest in any
script or extension that does multiple commits under the same repo
lock. (Thus, the test script tests both transplant and a custom script.)
The problem was that dirstate.status() failed to notice the change to
b when localrepo is about to do the second commit, meaning that change
gets left in the working directory. In the context of transplant, that
means either a crash ("RuntimeError: nothing committed after
transplant") or a silently inaccurate transplant, depending on whether
any other files were modified by the second transplanted changeset.
The fix is to make status() work a little harder when we have
previously marked files as clean (state 'normal') in the same process.
Specifically, dirstate.normal() adds files to self._lastnormal, and
other state-changing methods remove them. Then dirstate.status() puts
any files in self._lastnormal into state 'lookup', which will make
localrepository.status() read file contents to see if it has really
changed. So we pay a small performance penalty for the second (and
subsequent) commits in the same process, without affecting the common
case. Anything that does lots of status updates and checks in the
same process could suffer a performance hit.
Incidentally, there is a simpler fix: call dirstate.normallookup() on
every file updated by commit() at the end of the commit. The trouble
with that solution is that it imposes a performance penalty on the
common case: it means the next status-dependent hg command after every
"hg commit" will be a little bit slower. The patch here is more
complex, but only affects performance for the uncommon case.
Instead of computing the exact set of missing revlog revisions, we only
compute the set of missing/broken changesets. The resulting bundle can be
slightly bigger but we will be able to get rid of the ugly extranodes handling
in changegroupsubset.
This is a simple patch to make hg push/hg outgoing print their remote target
path even if the operation fails. I'm not sure if the original behavior was by
design.
This patch also changes one test to reflect the changed behaviour.
We check if the current bookmark is set to the first parent of the
dirstate. Is this the case we move the bookmark to most recent revision
on the current branch (where hg update will update you to).
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.
setcurrent refuses to set a new current bookmark if the current bookmark
points to the current dirstate. This restriction is not needed. A current
bookmark can point to a different bookmark.
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.
