Verify uses repo.cancopy() to detect whether a repo is a plain old
local repo, so it was giving a confusing error message when secret
changesets were present.
When mq changeset are secret, they don't appear in outgoing and won't be
pushed. So it's not necessary to abort the push.
The checkpush call is protected by lock to prevent race on phase.
If push failed we should not expect the pushed changeset to exist on remote.
The common set before the push is used for phase related operation instead of
common + missing.
Note:
* We still pull phase data even if push fails
* We still try to push data even if push fails (same than bookmark)
The ``discovery.prepush`` function was doing multiple things not related to
discovery. This changeset move some code into the ``localrepo.push`` method. The
old ``discovery.prepush`` function jobs is now restricted to checking for
multple head creation. It was then renamed ``discovery.checkheads``.
This new ``discovery.checkheads`` function may receive several other changes in
the future but we are a bit too much near the freeze for a wider refactoring.
New tags were written to .hgtags / .hglocaltags without updating or
invalidating the localrepo cache.
Before 462e6cfb1bac a lock was acquired soon after the new tags had been
written, and that invalidated the cache so the new tags for example could be
seen in pretxncommit hooks. With 462e6cfb1bac the lock had already been
acquired at this point and the missing cache invalidation was exposed.
The tag caches will now explicitly and immediately be invalidated when new tags
are added.
This commit add a whennodata list where extension can register a callback to be
called if no phase related data are found in the repository.
The goal is to ensure the existing extension that move phase data in 2.1 can
compute consistent phase boundary for existing repo.
The code now only exchange draft root and only care about movement related to
public//draft boundary.
There is multiple reason to simplify this code:
* Secret are never discovered anymore
* We decided to not support more the three existing phase
Removing phase index from pushkey (if ever decided) will be made in another commit.
This fix the lack phase movement when a locally secret changeset without added
children was pushed to the repository. In such case, this changeset would be
present in the bundle source, but not in the ``added`` variable.
This list will contains any node see in the source, not only the added one.
This is intended to allow phase to be move according what was pushed by client
not only what was added.
test-mq-cache.t did apparently look at stale cache content.
Testing with different locking mechanism happened to update the cache more
frequently and thus caused a test failure.
Simplifies client logic in multiple places since it encapsulates the
computation of the common and, more importantly, the missing node lists.
This also allows an upcomping patch to communicate precomputed versions of
these lists to clients.
The bugs seemed to show up when element not in future common changeset should
hold new hold phase data.
The whole phase push machinery was rewritten in the process.
current "localrepository._checknested()" uses specified path itself to
compare against subrepo pathes.
it is invoked from "hgsubrepo.subrepo()" or pathauditor (as callback),
and both use "os.sep" as separator.
this causes unexpected nesting check result, if subrepo configuration
uses "/" as path separator for sub repo path.
this path uses "/" to join path components (or apply "util.pconvert()"
on path) to normalize.
The contract for repo.destroyed() is that it is called whenever
changesets are destroyed, either by strip or by rollback. That
contract was inadvertently broken in 6c30b131b2ae, when we made a
chunk of code conditional on destroying one of the working dir's
parents. Oops: it doesn't matter *which* changesets are destroyed or
what their relationship is to the working dir, we should call
repo.destroyed() whenever we destroy changesets.
On Windows, we store symlinks as plain files with the link contents.
Via user error or NFS/Samba assistance, these files often end up with
'normal' file contents. Committing these changes thus gives an
invalid symlink that can't be checked out on Unix.
Here we filter out any modified symlink placeholders that look
suspicious when computing status:
- more than 1K (looks more like a normal file)
- contain NULs (not allowed on Unix, probably a binary)
- contains \n (filenames can't contain \n, very unusual for symlinks,
very common for files)
This changeset flips the default value of ui.commitsubrepos setting
from True to False and adds a --subrepos flag to commit.
The commit, status, and diff commands behave like this with regard to
recusion and the ui.commitsubrepos setting:
| recurses | recurses
| by default | with --subrepos
--------+---------------+----------------
commit: | commitsubrepo | True
status: | False | True
diff: | False | True
By changing the default from True to False, the table becomes
consistent in the two columns:
* without --subrepos on the command line, commit will abort if a
subrepo is dirty and status/diff wont show changes inside subrepos.
* with --subrepos, all three commands will recurse.
A --subrepos flag on the command line overrides the config settin.g
Older publish=True was:
1) Content of Publishing server are seen as public by client.
2) Any changegroup *added* to a publish=True server is public.
New definition are:
1) Content of Publishing server are seen as public by client.
2) Any changegroup *pushed* to a publish=True server is public.
See mercurial/phase.py documentation for exact final behavior
What is a "publishing repository"?
==================================
Setting a repository as "publishing" alter its behavior **when used as a
server**: all changesets are **seen** as public changesets by clients.
So, pushing to a "publishing" repository is the most common way to make
changesets public: pushed changesets are seen as public on the remote side and
marked as such on local side.
Note: the "publishing" property have no effects for local operations.
Old repository are publishing
=============================
Phase is the first step of a series of features aiming at handling mutable
history within mercurial. Old client do not support such feature and are unable
to hold phase data. The safest solution is to consider as public any changeset
going through an old client.
Moreover, most hosting solution will not support phase from the beginning.
Having old clients seen as public repositories will not change their usage:
public repositories where you push *immutable* public changesets *shared* with
others.
Why is "publishing" the default?
================================
We discussed above that any changeset from a non-phase aware repository should
be seen as public. This means that in the following scenario, X is pulled as
public::
~/A$ old-hg init
~/A$ echo 'babar' > jungle
~/A$ old-hg commit -mA 'X'
~/A$ cd ../B
~/B$ new-hg pull ../A # let's pretend A is served by old-hg
~/B$ new-hg log -r tip
summary: X
phase: public
We want to keep this behavior while creating/serving the A repository with
``new-hg``. Although committing with any ``new-hg`` creates a draft changeset.
To stay backward compatible, the pull must see the new commit as public.
Non-publishing server will advertise them as draft. Having publishing repository
the default is thus necessary to ensure this backward compatibility.
This default value can also be expressed with the following sentence: "By
default, without any configuration, everything you exchange with the outside is
immutable.". This behaviour seems sane.
Why allow draft changeset in publishing repository
=====================================================
Note: The publish option is aimed at controlling the behavior of *server*.
Changeset in any state on a publishing server will **always*** be seen as public
by other client. "Passive" repository which are only used as server for pull and
push operation are not "affected" by this section.
As in the choice for default, the main reason to allow draft changeset in
publishing server is backward compatibility. With an old client, the following
scenario is valid::
~/A$ old-hg init
~/A$ echo 'babar' > jungle
~/A$ old-hg commit -mA 'X'
~/A$ old-hg qimport -r . # or any other mutable operation on X
If the default is publishing and new commits in such repository are "public" The
following operation will be denied as X will be an **immutable** public
changeset. However as other clients see X as public, any pull//push (or event
pull//pull) will mark X as public in repo A.
Allowing enforcement of public changeset only repository through config is
probably something to do. This could be done with another "strict" option or a
third value config for phase related option (mode=public, publishing(default),
mutable)
