The outgoing object gains an "excluded" members holding all changesets which
were excluded because there where secret.
The core discovery code now remove secret changeset from discovery by default.
This means that any command relying on discovery will exclude secret changeset.
Most notable one are outgoing and bundle. (But bundle with and explicit
``--base`` still allow to bundle outgoing changeset.
The last line of a non newline-terminated file would mix with the first line of
the next file in multiple-file listings before this patch.
Possible compatibility issue: no longer possible to tell from the annotate
output if the file is terminated by new line or not.
``{phaseidx}`` is providing the phase index as integer. This integer
representation is useful when people need to use the fact that phase are
ordered.
Test keep using the number version for readability purpose.
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.
As of 1ffaca626da1 (first released as part of Mercurial 2.0), the rebase command
accepted ONLY revsets for the source and base arguments and no longer accepted
old-style revision specifications. As a result, some revision names were no
longer recognised, e.g.
hg rebase --base br-anch
abort: unknown revision 'br'!
These arguments are now interpreted first as old-style revision specifications,
then as revsets when no matching revision is found. This restores backwards
compatibility with releases prior to 2.0.
Don't lock/write on operations that should be readonly (status).
Always lock when writing the lfdirstate (rollback).
Don't write lfdirstate until after committing; state isn't actually changed
until the commit is complete.
Implementing addremove correctly in largefiles is tricky, becuase the original
addremove function does not call into any of the add or remove function we've
already overridden in the extension. So the trick is to implement addremove
without duplicating any code.
This patch implements addremove by pulling out the interesting parts of
override_add() and override_remove() into generic utility functions, and
using those to handle the largefiles in addremove. Then a matcher is
installed that will ignore all largefiles, and the original addremove
function is called to take care of the regular files in addremove.
A small bit of monkey patching is used to make sure that remove_largefiles()
notifies the user when a file is removed by addremove and also makes sure
the removal of largefiles doesn't interfer with the original addremove's
operation of removing the standin.
This patch makes "hg remove" work the same way on largefiles as it does on
regular Mercurial files. If you try to remove an added largefile, the removal
fails and you are instead prompted to use "hg forget" to undo the add.
The GPLv3 FAQ suggests to upgrade by
[...] replace all your existing v2 license notices (usually at the
top of each file) with the new recommended text available on the GNU
licenses howto. It's more future-proof because it no longer includes
the FSF's postal mailing address.
This removes the postal address, but leaves the version number at 2+.
The existing copy detection API was designed with merge in mind and
was ill-suited for doing status/diff. The new pathcopies
implementation gives more accurate, easier to use results for
comparing two revisions, and is much simpler to understand.
Test notes:
- test-mv-cp-st.t results finds more renames in the reverse direction now
- test-mq-merge.t was always wrong and duplicated a copy in diff that
was already present in one of the parent revisions
Mercurial assumes that the shell on remote servers over ssh servers uses unix
quoting rules. Tests using dummyssh are however also run on windows where cmd
doesn't parse single quotes like on unix.
This hack replaces the single quotes with double quotes on windows - that is
enough to make test-ssh.t pass after 7bec00a7d7a6.
"hg qpush" causes unexpected behavior, if case preservation on case
insensitive filesystem is not enough.
this patch adds the test using mixed-case filenames to reproduce this
problem on any case insensitive filesystems.
some problematic encoding (e.g.: cp932) uses ASCII alphabet characters
in byte sequence of multi byte characters.
"str.lower()" on such byte sequence may treat distinct characters as
same one, and cause unexpected log matching.
this patch uses "encoding.lower()" instead of "str.lower()" to
normalize strings for compare.
some problematic encoding (e.g.: cp932) uses ASCII alphabet characters
in byte sequence of multi byte characters.
"str.lower()" on such byte sequence may treat distinct characters as
same one, and cause unexpected log matching.
this patch uses "encoding.lower()" instead of "str.lower()" to
normalize strings for compare.
Any secret changesets will be excluded from pull and push. Phase data are
properly synchronized on pull and push if a changeset is seen as secret locally
but is non-secret remote side.
This patch does not handle the case of a changeset secret on remote but known
locally.
this patch makes branch merging abort when merged changesets have same
file in different case on case insensitive filesystem.
this patch does not prevent linear update which merges between target
and working contexts, because 'branchmerge' is False in such case.
The largefiles extension prevents users from adding a normal file
named 'foo' if there is already a largefile with the same name.
However, there was a loop-hole: when merging, it was possible to bring
in a normal file named 'foo' while also having a '.hglf/foo' file.
This patch fixes this by extending the manifest merge to deal with
these kinds of conflicts. If there is a normal file 'foo' in the
working copy, and the other parent brings in a '.hglf/foo' file, then
the user will be prompted to keep the normal file or the largefile.
Likewise for the symmetric case where a normal file is brought in via
the second parent. The prompt looks like this:
$ hg merge
foo has been turned into a largefile
use (l)argefile or keep as (n)ormal file?
After the merge, either the '.hglf/foo' file or the 'foo' file will
have been deleted. This would cause status to return output like:
$ hg status
M foo
R foo
To fix this, the lfiles_repo.status method is changed so that a
removed normal file isn't shown if there is largefile with the same
name, and vice versa for largefiles.
If a largefile is introduced on the branch that is merged into the
working copy, then 'hg status' would abort with an error like:
$ hg status
abort: .hglf/foo@33fdd332ec: not found in manifest!
The problem was that the largefiles status code only looked in the
first parent for the largefile. Largefiles are now always reported as
modified if they don't exist in the first parent -- this matches the
behavior of localrepo.status for normal files.
Before:
>>> str(url('file:///c:/tmp/foo/bar'))
'file:c%3C/tmp/foo/bar'
After:
>>> str(url('file:///c:/tmp/foo/bar'))
'file:///c%3C/tmp/foo/bar'
The previous behaviour had no effect on mercurial itself (clone command for
instance) because we fortunately called .localpath() on the parsed URL.
hgsubversion was not so lucky and cloning a local subversion repository on
Windows no longer worked on the default branch (it works on stable because
2b62605189dc defeats the hasdriveletter() test in url class).
I do not know if the %3C is correct or not but svn accepts file:// URLs
containing it. Mads fixed it in 2b62605189dc, so we can always backport should
the need arise.
