This should be faster and more future-proof. Calls where the result is to be
sorted using util.sort() have been left unchanged. Calls to .items() on
configparser objects have been left as-is, too.
This change ensures that removes happen first in applyupdates(). This avoids
issues where we try to make a case-only rename of a file on a case insensitive
system. Without this patch, the add of the new name happens before the remove
of the old one - which results in the file not existing, as the two names are
effectively the same.
With the patch, the old name gets removed then the new one gets added, which
is always safe.
- 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)
As mentioned in msg5349 in issue988, "hg update" doesn't take into account
uncommitted copies. To reproduce:
----------------
hg init repo
cd repo
touch foo
hg ci -Am 'add foo'
echo >> foo
hg ci -m 'change foo'
hg up -C 0
hg mv foo bar
HGMERGE=false thg --debug -y update
--------------------------
A similar problem happens with hg merge --force.
I'm attaching a possible patch.
Sets HG_MY_ISLINK, HG_OTHER_ISLINK, HG_BASE_ISLINK in environment. Without these variables, it's impossible for the merge application to know whether the 'other' and 'base' files were symlinks in their original contexts. For the purposes of the merge they are always emitted as small text files.
After a hg merge, we want to include in the commit all the files that we
got from the second parent, so that we have the correct file-level
history. To make them visible to hg commit, we try to mark them as dirty.
Unfortunately, right now we can't really mark them as dirty[1] - the
best we can do is to mark them as needing a full comparison of their
contents, but they will still be considered clean if they happen to be
identical to the version in the first parent.
This changeset extends the dirstate format in a compatible way, so that
we can mark a file as dirty:
Right now we use a negative file size to indicate we don't have valid
stat data for this entry. In practice, this size is always -1.
This patch uses -2 to indicate that the entry is dirty. Older versions
of hg won't choke on this dirstate, but they may happily mark the file
as clean after a full comparison, destroying all of our hard work.
The patch adds a dirstate.normallookup method with the semantics of the
current normaldirty, and changes normaldirty to forcefully mark the
entry as dirty.
This should fix issue522.
[1] - well, we could put them in state 'm', but that state has a
different meaning.
When merging rev1 and rev2, we want to search for copies that happened
in rev1 but not in rev2 and vice-versa. We were starting the search at
rev1/rev2 and then going back, stopping as soon as we reached the revno
of the ancestor, but that can miss some cases (see the new
test-issue672).
Now we calculate the revisions that are ancestors of rev1 or rev2 (but
not both) and make sure the search doesn't stop too early.
Simplified test provided by mpm, based on a test case provided by
Edward Lee.
