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
Before this patch, "@99" suffixed bookmark may be updated unexpectedly
by the bookmark value on the remote side at "hg pull", if all of "@1"
to "@99" suffixed bookmarks exist in the local repository, because
variable "n" still refers "@99" suffixed bookmark after the loop to
examine "@num" suffixes, even though it already exists in the local
repository.
This patch prevents divergent bookmark from being updated
unexpectedly, and shows warning message in such situation.
This patch uses original python script "seq.py" instead of "seq"
command to create sequence numbers in the test, because "seq" command
may not be available: it isn't defined in recent POSIX specification
(POSIX.1-2001 2013 Edition or XPG7)
Although Python supports `X = Y if COND else Z`, this was only
introduced in Python 2.5. Since we have to support Python 2.4, it was
a very common thing to write instead `X = COND and Y or Z`, which is a
bit obscure at a glance. It requires some intricate knowledge of
Python to understand how to parse these one-liners.
We change instead all of these one-liners to 4-liners. This was
executed with the following perlism:
find -name "*.py" -exec perl -pi -e 's,(\s*)([\.\w]+) = \(?(\S+)\s+and\s+(\S*)\)?\s+or\s+(\S*)$,$1if $3:\n$1 $2 = $4\n$1else:\n$1 $2 = $5,' {} \;
I tweaked the following cases from the automatic Perl output:
prev = (parents and parents[0]) or nullid
port = (use_ssl and 443 or 80)
cwd = (pats and repo.getcwd()) or ''
rename = fctx and webutil.renamelink(fctx) or []
ctx = fctx and fctx or ctx
self.base = (mapfile and os.path.dirname(mapfile)) or ''
I also added some newlines wherever they seemd appropriate for readability
There are probably a few ersatz ternary operators still in the code
somewhere, lurking away from the power of a simple regex.
This change touches every module in which repository.opener was being used, and
changes it for the equivalent repository.vfs. This is meant to make it easier
to split the repository.vfs into several separate vfs.
It should now be possible to remove localrepo.opener.
bookmarks.compare() previously lumped identical bookmarks in the
"invalid" bucket. This patch adds a "same" bucket.
An 8-tuple for holding this state is pretty gnarly. The return value
should probably be converted into a class to increase readability. But
that is beyond the scope of a patch intended to be a late arrival to
stable.
Instead of manually writing bookmarks when they are updated, we can just record this
update to the transaction and rely on it to update the on-disk file.
If we want to handle bookmarks in a transaction we need to decouple the file
handling and the actual production of the content. This is similar to how we
handle phases in transaction.
We do all the things in one go now, updating existing bookmark, adding new ones,
and overwriting the ones explicitly specified for --bookmark. This impacts the
tests by removing some duplicated or unnecessary output.
We translate the "url we update from" and "the url in the config" into their
canonical representation. This is useful for urls that have multiple equivalent
forms:
/foo/bar/ == file:/foo/bar/ == file:///foo/bar
eg: hg pull --config path.bar=/foo/bar/ file:/foo/bar
Previously a bookmark pushkey would be rejected if the specified 'old' value
didn't match the servers 'current' value. This change allows this situation, as
long as the 'current' server value equals the 'new' pushkey value already.
We are trying to write a hook that forces a server bookmark to move forward,
using a changegroup hook. If the user also pushed the bookmark, they would get
an error, since they computed their pushkey (old,new) pair before the server
moved the bookmark. Long term, bundle2 will let us do this more smartly, but
this change seems reasonable for now.
