Backing out a changeset that is before a named branch branchpoint was
making the reverse changeset the tip of the old branch, which is wrong
and very confusing. So instead, we put it on the current named branch.
This fixes passing back fail messages mistaken for skip messages when
running with parallel jobs because run_children() only expects one message per
fail.
- complain about attempts to merge with ancestor
- when updating, differentiate between
- crossing named branches with no local changes (jump)
- crossing named branches with local changes (complain)
- nonlinear update on the same named branch, no changes (complain some more)
- nonlinear update on the same named branch, changes (different complaining)
/tmp is symlinked in MacOSX therefore test scripts as well as python modules
are installed in a symlinked location. coverage.py uses abspath() to normalize
its inputs which fails if these are referencing real paths. Use realpath()
instead.
- Added files are never deleted (only removed with --force).
- Modified files can only be removed with --force.
- With --after, only deleted files are removed.
- With --after --force, all files are removed but not deleted.
With this change, "hg clone" looks like this:
% hg clone http://example.com/repo/big big
requesting all changes
adding changesets
adding manifests
adding file changes
added XXX changesets with XXX changes to XXX files
updating working directory
XXX files updated, XXX files merged, XXX files removed, XXX files unresolved
So the user sees
% hg clone http://example.com/repo/big big
requesting all changes
adding changesets
adding manifests
adding file changes
added XXX changesets with XXX changes to XXX files
updating working directory
while Mercurial is writing to disk to populate the working directory
With this change, "hg clone" looks like this:
% hg clone big big-work
updating working directory
XXX files updated, XXX files merged, XXX files removed, XXX files unresolved
This should fix the race where
hg commit foo
<change foo without changing its size>
happens in the same second and status is fooled into thinking foo
is clean.
A configuration item is used to determine the timeout, since different
filesystems may have different requirements (I think VFAT needs 3s,
while most Unix filesystems are fine with 1s).
- Example: "hg tag -r 42 build-25 beta-1" will add tags build-25 and beta-1
for rev 42.
- The deprecated and undocumented usage "hg tag arg1 arg2" used to emit a
warning, then add tag arg1 for rev arg2 (equivalent to "hg tag -r arg2 arg1").
It will now add tags arg1 and arg2 for the current revision.
- If one tag triggers an error, no tags are added/removed (all or nothing).