Cosmetic cleanups. Fix comment typo referring to the notion of multiple tips.
Make variable describing a generator end in 'gen'.
Fix another var containing a node not to end with 'rev'.
The fix introduced in 3509b9cf8f86 was only partially successful. It is correct
to turn dirstate 'm' merge records into normal/dirty ones but copy records are
lost in the process. To adjust them as well, we need to look in the first
parent manifest to know which files were added and preserve only related
records. But the dirstate does not have access to changesets, the logic has to
moved at another level, in localrepo.
Here is a script illustrating the previous behaviour:
The merge brings a new file 'b' from remote
$ hg merge 1 --debug
searching for copies back to rev 1
unmatched files in other:
b
resolving manifests
overwrite: False, partial: False
ancestor: 07f494440405, local: 540395c44225+, remote: 102a90ea7b4a
b: remote created -> g
updating: b 1/1 files (100.00%)
getting b
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Delete but do not remove b
$ rm b
$ hg st
! b
The commit succeeds
$ hg commit -m merge
$ hg parents --template "{rev} {desc|firstline} files: {files}\n"
3 merge files:
$ hg st
! b
b changes were ignored, but even b existence was ignored
$ hg manifest
a
This happens because localrepo.commitctx() checks the input ctx.files(), which
is empty for workingctx.files() only returns added, modified or removed
entries, and bypass files/manifest updates completely. So the committed
revision manifest is the same as its first parent one, not containing the 'b'
file.
This patch forces the commit to abort in presence of a merge and missing files.
test-merge4.t is modified accordingly as it was introduced to check hg was not
just terminating with a traceback (5cc0d3ba11f9).
bookmarks is copied to journal.bookmarks differently from how dirstate is
copied to journal.dirstate. The different way is less robust, which can render
the repo unpushable by other users if the first pushing user aborts their
transaction.
The underlying cause is that the copyfile method attempts an unnecessary chmod,
which fails if the user is not the owner of the journal.bookmarks file.
This patch makes the bookmarks journaling more consistent with the rest of the
journaling, and will allow users to update lingering journal.bookmarks files
that they're not the owners of.
New users of filecache use different names for the function used to compute
the runtime path of the cached file.
Users should subclass filecache and provide their own version of this
function to call the appropriate join function on 'obj' (an instance
of the class that its member function was decorated).
when pattern which does not match against any files in working context
is specified, current implementation of 'localrepository.status()'
decides whether warning message about it should be shown or not by
'f not in context'
this works correctly for 'file pattern', but not for 'directory
pattern', because 'f not in context' always returns True for
directories, even if they are related to the context.
this patch uses 'changectx.dirs()' to examine whether specified
pattern is related to the context as a directory or not.
Files are being replaced by rollback but the corresponding data in localrepo
isn't actually updated for things like bookmarks, phases, etc. Then when
rollback is done, the cache is updated thinking it has the most up-to-date
data, where in fact it is still pre-rollback.
We clear _filecache to force everything to be recreated.
Currently we have the following return codes if nothing is found:
commit incoming outgoing pull push
intended 1 1 1 1 1
documented 1 1 1 0 1
actual 1 1 1 0 0
This fixes the lower-right entry.
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 the contents of .hgsubstate are stale (either because they've
manually been tweaked or partial updates have confused it), we get
confused about whether it actually needs committing.
So instead, we actively consult the parent's substate and compare it
the actual current state when deciding whether it needs committing.
Side effect: lots of "committing subrepo" messages that didn't
correspond with real commits disappear.
This change is fairly invasive for a fairly obscure condition, so it's
kept on the default branch.
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)
You can get into trouble if you commit, update back to an older
changeset, and then rollback. The update removes your valuable changes
from the working dir, then rollback removes them history. Oops: you've
just irretrievably lost data running nothing but core Mercurial
commands. (More subtly: rollback from a shared clone that was already
at an older changeset -- no update required, just rollback from the
wrong directory.)
The fix assumes that only "commit" transactions have irreplaceable
data, and allows rolling back non-commit transactions as always. But
when rolling back a commit, check that the working dir is checked out
to tip, i.e. the changeset we're about to destroy. If not, abort. You
can get back the old (dangerous) behaviour with --force.
If the working dir parent was destroyed by rollback, then the old
behaviour is perfectly reasonable: restore dirstate, branch, and
bookmarks. That way the working dir moves back to an existing
changeset rather than becoming an orphan.
But if the working dir parent was unaffected -- say, you updated to an
older changeset and then did rollback -- then it's silly to restore
dirstate and branch. So don't do that. Leave the status of the working
dir alone. (But always restore bookmarks, because that file refers to
changeset IDs that may have been destroyed.)
- clarify how we parse undo.desc
- fix bad grammar in an error message
- factor out ui local
- rename some local variables
- standardize string quoting
This is extremely handy for those occasional circumstances where you
need to edit .hg/sharedpath manually, since modern Unix text editors
make it surprisingly difficult to create a text file with no trailing
newline.
The usual contract is that close() makes your writes permanent, so
atomictempfile's use of close() to *discard* writes (and rename() to
keep them) is rather unexpected. Thus, change it so close() makes
things permanent and add a new discard() method to throw them away.
discard() is only used internally, in __del__(), to ensure that writes
are discarded when an atomictempfile object goes out of scope.
I audited mercurial.*, hgext.*, and ~80 third-party extensions, and
found no one using the existing semantics of close() to discard
writes, so this should be safe.
