This allows even further customization via extensions for printing
bookmarks. For example, in hg-git this would allow printing remote refs
by just modifying the 'bmarks' parameter instead of reimplementing the
old commands.bookmarks method.
Furthermore, there is another benefit: now multiple extensions can
chain their custom data to bookmark printing. Previously, an extension
could have conflicting bookmark output due to which loaded first and
overrode commands.bookmarks. Now they can all play nicely together.
Again, commands.bookmark is getting too large. checkconflict already has
a lot of state and putting it in the bmstore makes more sense than
having it as a closure. This also allows extensions a place to override
this behavior.
While we're here, add a documentation string because, well, we should be
documenting more of our methods.
commands.bookmark has grown quite large with two closures already. Let's
split this up (and in the process allow extensions to override the
default behavior).
Since we no longer set '_clean = False' during the initialization loop, we can
move the attribute assignment earlier in the function for clarity.
(no speed improvement expected or measured ;-) )
The bmstore '__setitem__' method is setting an extra flag that is not needed
during initialization. Skipping the method will allow further cleanup and yield
some speedup as a side effect.
Before:
! wall 0.009120 comb 0.010000 user 0.010000 sys 0.000000 (best of 312)
After:
! wall 0.007874 comb 0.010000 user 0.010000 sys 0.000000 (best of 360)
Since we already have an exception context open, for other thing, we can
simplify the code a bit and rely on exception handling for invalid lines.
Speed is not the main motivation for this changes. However as I'm in the middle
of benchmarking things we can see a small positive impact.
Before:
! wall 0.009358 comb 0.000000 user 0.000000 sys 0.000000 (best of 303)
After:
! wall 0.009173 comb 0.010000 user 0.010000 sys 0.000000 (best of 310)
We know the content of the file is supposed to be full hex. So we can do the
translation ourselves and directly check if the node is known.
As nice side effect we now have proper error handling for invalid node value.
Before:
! wall 0.021580 comb 0.020000 user 0.020000 sys 0.000000 (best of 134)
After:
! wall 0.009342 comb 0.010000 user 0.010000 sys 0.000000 (best of 302)
Skipping the attribute lookup up raise a significant speedup.
Example on a repository with about 4000 bookmarks.
Before:
! wall 0.026027 comb 0.020000 user 0.020000 sys 0.000000 (best of 112)
After:
! wall 0.021580 comb 0.020000 user 0.020000 sys 0.000000 (best of 134)
(This is also in its own changeset to clarify the perf win from another coming
changesets)
This method is only used internally by destutil, and it's obscure
enough I'm willing to just move it without a deprecation warning,
especially since the new method has more constrained functionality.
Design-wise I'd also like to get active bookmark handling folded into
the bookmark store, so that we don't squirrel away an extra attribute
for the active bookmark on the repository object.
Before this patch, checking HG_PENDING in bookmarks.py might cause
unintentional reading unrelated '.hg/bookmarks.pending' in, because it
just examines existence of HG_PENDING environment variable.
This patch uses txnutil.trypending() to check HG_PENDING strictly.
This patch also changes share extension.
Enabling share extension (+ bookmark sharing) makes
bookmarks._getbkfile() receive repo to be shared (= "srcrepo"). On the
other hand, HG_PENDING always refers current working repo (=
"currepo"), and bookmarks.pending is written only into currepo.
Therefore, we should try to read .hg/bookmarks.pending of currepo in
at first. If it doesn't exist, we try to read .hg/bookmarks of srcrepo
in.
Even after this patch, an external hook spawned in currepo can't see
pending changes in currepo via srcrepo, even though such changes
become visible after closing transaction, because there is no easy and
cheap way to know existence of pending changes in currepo via srcrepo.
Please see https://www.mercurial-scm.org/wiki/SharedRepository, too.
BTW, this patch may cause failure of bisect in the repository of
Mercurial itself, if examination at bisecting assumes that an external
hook can see all pending changes while nested transactions across
repositories.
This invisibility issue will be fixed by subsequent patch, which
allows HG_PENDING to refer multiple repositories.
os.environ is a dictionary which has string elements on Python 3. We have
encoding.environ which take care of all these things. This is the first patch
of 5 patch series which tend to replace the occurences of os.environ with
encoding.environ as using os.environ will result in unusual behaviour.
Binary bookmark format should be used internally. It doesn't make sense to have
optional parameters `srchex` and `dsthex`. This patch removes them. It will
also be useful for `bookmarks` bundle2 part because unnecessary conversions
between hex and bin nodes will be avoided.
Next commit will remove optional parameters from `compare()` function.
Let's rename `compare()` to `comparebookmarks()` to avoid ambiguity from
callers from external extensions.
`bookmarks` bundle2 part will work with binary nodes. To avoid unnecessary
conversions between binary and hex nodes let's add `listbinbookmarks()` that
returns binary nodes. For now this function is a copy-paste of
listbookmarks(). In the next patch this copy-paste will be removed.
Cached attribute repo._bookmarks uses stat of '.hg/bookmarks' and
'.hg/bookmarks.current' files to examine validity of cached
contents. If writing these files out keeps ctime, mtime and size of
them, change is overlooked, and old contents cached before change
isn't invalidated as expected.
To avoid ambiguity of file stat, this patch writes '.hg/bookmarks' and
'.hg/bookmarks.current' files out with checkambig=True.
This patch is a part of "Exact Cache Validation Plan":
https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
This further centralizes the handling of bookmark storage, and will
help get some lingering bookmarks business out of localrepo. Right
now, this change implies reading of the active bookmark to also imply
reading all bookmarks from disk - for users with many many bookmarks
this may be a measurable performance hit. In that case, we should
migrate bmstore to be able to lazy-read its properties from disk
rather than having to eagerly read them, but I decided to avoid doing
that to try and avoid some potentially complicated filecache decorator
issues.
This doesn't move the logic for writing the active bookmark into a
transaction, though that is probably the correct next step. Since the
API probably needs to morph a little more, I didn't bother marking
bookmarks.{activate,deactivate} as deprecated yet.
When reading over static http, the file isn't actually opened until
the readlines() call, so we have to check for ENOENT IOErrors here
too. This is necessary so that we can use the bmstore everywhere for
managing the active bookmark, which will be true in the next change.
This function does not collaborate with the transaction and must disappear. As
we have likely a lot of third party users, we make it deprecated to let them some
time to upgrade their code.
Thanks goes to Laurent Charignon for cleanup the last remains of the 'write'
method.
I'm about to move active-bookmark management into the bmstore. I'd
like to avoid re-writing the bookmarks data (as distinct from the
active bookmark file) if possible, so let's introduce some
dirty-tracking early.
Before this patch, 'bmstore.write()' always write in-memory bookmark
changes into '.hg/bookmarks' regardless of transaction activity.
If 'bmstore.write()' is invoked inside a transaction and it writes
changes into '.hg/bookmarks', then:
- original bookmarks aren't restored at failure of that transaction
This breaks "all or nothing" policy of the transaction.
BTW, "hg rollback" can restore bookmarks successfully even before
this patch, because original bookmarks are saved into
'.hg/journal.bookmarks' at the beginning of the transaction, and
it (actually renamed as '.hg/undo.bookmarks') is used by "hg
rollback".
- uncommitted bookmark changes are visible to other processes
This is a kind of "dirty read"
For example, 'rebase.rebase()' implies 'bmstore.write()', and it may
be executed inside the transaction of "hg unshelve". Then, intentional
aborting at the end of "hg unshelve" transaction doesn't restore
original bookmarks (this is obviously a bug).
This patch uses 'bmstore.recordchange()' instead of actual writing by
'bmstore._writerepo()', if any transaction is active
This patch also removes meaningless restoring bmstore explicitly at
the end of "hg shelve".
This patch doesn't choose fixing each 'bmstore.write()' callers as
like below, because writing similar code here and there is very
redundant.
before:
bmstore.write()
after:
tr = repo.currenttransaction()
if tr:
bmstore.recordchange(tr)
else:
bmstore.write()
Even though 'bmstore.write()' itself may have to be discarded by
putting bookmark operations into transaction scope, this patch chose
fixing it to implement "transactional dirstate" at first.
I saw an issue in an extension that we develop where we were writing bookmarks
without holding the wlock. Another extension was taking a lock at the same time
and wiped out the bookmarks we were about to write. This patch adds a
devel-warning to urge people to fix their invalid code.
Any changes to bookmarks used to touch the changelog to ensure hgweb was
reloaded. This was fairly hacky and stops working when bookmarks are moved as
part of the transaction. As hgweb is now explicitly tracking bookmark changes,
we can remove this hack (and no tests break).
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
Context: the result of computehidden, used to compute the 'visible' revisions
is cached. Its output can change when:
1) new obsolete commits are created
2) new bookmarks are created or deleted
3) new tags are created or deleted
4) the parents of the working copy change
We currently correctly invalidate the cache only in the case 1).
This patch fixes the second case (bookmarks) by invalidating the cache once
a bookmark is added or removed.
When we explicitly requested to update a bookmark but the bookmark location was
missing locally, we used to silently ignore the case. We now issue a message
about it to point that something wrong is going on.
By chance, we fixed all the cases where is case happened (for explicit pulling
only, issue4700 is still open). But I think it is still valuable to have a
warning in place in case such issue is reintroduced.
This patch have been tested against issue4689 test (but without issue4689 fix).
It give the better but expected failure seen below:
> --- /home/pyd/src/mercurial-dev/tests/test-bookmarks-pushpull.t
> +++ /home/pyd/src/mercurial-dev/tests/test-bookmarks-pushpull.t.err
> @@ -337,12 +337,12 @@
> adding manifests
> adding file changes
> added 1 changesets with 1 changes to 1 files
> - updating bookmark Y
> + remote bookmark Y point to locally missing 0d60821d2197
> (run 'hg update' to get a working copy)
> $ hg book
> * @ 1:0d2164f0ce0d
> X 1:0d2164f0ce0d
> - Y 5:35d1ef0a8d1b
> + Y 4:b0a5eff05604
> Z 1:0d2164f0ce0d
>
> Update a bookmark right after the initial lookup -r (issue4700)
> @@ -387,12 +387,11 @@
> adding manifests
> adding file changes
> added 1 changesets with 1 changes to 1 files
> - updating bookmark Y
> (run 'hg update' to get a working copy)
> $ hg book
> * @ 1:0d2164f0ce0d
> X 1:0d2164f0ce0d
> - Y 6:0d60821d2197
> + Y 4:b0a5eff05604
> Z 1:0d2164f0ce0d
> $ hg -R $TESTTMP/pull-race book
> @ 1:0d2164f0ce0d
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
