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.
Previously this function accepted two optional parameters that were unused by
any callers and complicated the function.
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.
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.
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.
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.
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.
Before this patch, "hg outgoing -B" shows only difference of bookmarks
between two repositories, and it isn't user friendly.
This patch shows detailed status about outgoing bookmarks at "hg
outgoing -B".
To avoid breaking backward compatibility with other tool chains, this
patch shows status, only if --verbose is specified,
Before this patch, "hg incoming -B" shows only difference of bookmarks
between two repositories, and it isn't user friendly.
This patch shows detailed status about incoming bookmarks at "hg
incoming -B".
To avoid breaking backward compatibility with other tool chains, this
patch shows status, only if --verbose is specified,
Before this patch, "hg outgoing -B" shows only bookmarks added
locally. Then, users can't know about bookmarks below before "hg push"
execution.
- deleted locally (even though it may be added remotely from "hg pull" view)
- advanced locally
- diverged
- changed (= remote revision is unknown for local)
This patch shows such bookmarks, too.
Before this patch, "hg incoming -B" shows only bookmarks added
remotely. Then, users can't know about bookmarks below before "hg
pull" execution.
- advanced remotely
- diverged
- changed (remote revision is unknown for local)
This patch shows such bookmarks, too.
This patch adds utility function "summary()", to replace comparing
bookmarks in "commands.summary()". This replacement finishes
centralizing the logic to compare bookmarks into "bookmarks.compare()".
This patch also adds test to check summary output with
incoming/outgoing bookmarks, because "hg summary --remote" is not
tested yet on the repository with incoming/outgoing bookmarks.
This test uses "(glob)" to ignore summary about incoming/outgoing
changesets.
This replacement makes enhancement of "show outgoing bookmarks" easy,
because "compare()" can detect more detailed difference of bookmarks
between two repositories.
This replacement makes enhancement of "show incoming bookmarks" easy,
because "compare()" can detect more detailed difference of bookmarks
between two repositories.
Before this patch, "@number" suffixed bookmark may be newly created at
each "hg pull" from the remote repository, if the bookmark in remote
repository diverges from one in local one.
This causes unexpected increase of "@number" suffixed bookmarks.
This patch reuses "@number" suffixed bookmark, if it refers the
changeset which is referred by the same bookmark in the remote
repository.
Before this patch, available "@number" suffix is searched before
"@pathalias" suffix, even though the latter has higher priority than
the former if the latter exits.
This patch checks "@pathalias" suffix before available "@number" for
efficiency.
When an URL has multiple path definitions, the first one is used for
"pathalias" after this patch, even though the last one is used before
this patch, because:
- this choice can terminate loop immediately for efficiency
- such case seems to be rare