largefiles and lfconvert do dirty hacks with dirstate, so to avoid writing that
as a side effect of the wlock release we clear dirstate first.
To avoid confusing lock validation algorithms in error situations we unlock
_before_ removing the target directory.
brendan mentioned on IRC that b64decode raises a TypeError too, but while the
previous exception type may be better in general, it is much easier to make it
behave like the related C code and changes nothing for mercurial itself.
When we encounter a corrupt index, we "fail" the init but our
destructor still gets called. On some systems, this was causing us to
attempt to decref a dangling to self->data.
Note that aborting in subrepo.state() prevents "repairing" commands like revert
to be issued. The user will have to edit the .hgsubstate manually (but he
probably had already otherwise this would not be failing). The same behaviour
already happens with invalid .hgsub entries.
Let R be a repo served by an hg daemon on a machine with an empty largefiles
cache. Pushing a largefiles repo to R will result in a no-such-file-or-directory
OSError because putlfile will attempt to create a temporary file in
R/.hg/largefiles, which does not yet exist.
This patch also adds a regression test for this scenario.
largefiles status implementation attemps to rewrite the input match objects to
match the "standins" as well as the regular files. When fixing the directories
listed in match.files(), if there was related standin entry, it was kept and
the original path discarded. But directories can appear both as regular and
standin entries.
Since version 1.8 (released on 2011-03-01), Mercurial doesn't use pywin32 any
more. The old fallback mechanism to use C:\Mercurial\Mercurial.ini if pywin32 is
not installed was removed in 1fa0a833f143.
This is most easily verified using valgrind on a long-running
process, as the leak has no visible consequences during normal
one-shot command usage.
In one window:
valgrind --leak-check=full --suppressions=valgrind-python.supp \
python ./hg serve
In another:
for ((i=0;i<100;i++)); do
curl -s http://localhost:8000/file/tip/README >/dev/null
done
valgrind should report no leaks.
The collapse configuration setting for hgweb was recently
introduced, but the help text was unfortunately omitted from the
patch concerned. This patch provides a suitable help text.
There is currently no clear link between the help for log
and the help on templates. The log option is --template
but the template help is 'help templating' or 'help templates'.
This patch makes 'hg help template' work and also adds a
note into the log help explaining where to find more info.
The initial version was to take the "Revision" field from svn info. It works
but produces false positive when parent paths are being moved or unrelated
changes are being committed, causing it to change while the svn checkout itself
remains the same. To avoid spurious commit, we took "Revision" and "Last
Changed Rev" for general comparison and kept the latter to answer "what is your
revision?" question. This is better but fails when the subrepo path exists at
"Revision" but not at "Last Changed Rev". This patch adds a check for this, and
returns "Revision" if the path does not exist. We try to avoid doing this as
much as possible at it implies an extra, *remote* call.
Messing with the dirstate before the intermediate commit seems error prone.
Instead, commit and recompute the copies with copies.pathcopies(), then use
that with commitctx().
Since copies.pathcopies() does not support file replacement very well, the
whole .renamed() condition in samefile() is removed and the "file replacement
caused by differing copy source" effect is discarded.
Test shamelessly stolen from Idan Kamara <idankk86@gmail.com>
The weirdness is --amend let you replace one file with another with same data
and flags if the new file copy record differ from the one in the parent
revision. In theory, there is no problem with this kind of thing, subversion
supports it, but here we see log and status disagree. The reason is log reads
the copy record from the filelog, while status calls copies.pathcopies() which
eventually invokes some expensiveness argument to discard this case (copies.py,
_forwardcopies(), line 132). Since the next patch will side with pathcopies(),
I prefer to call this behaviour a bug.
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.
Brifly explain why rewriting subrepository paths can be necessary.
Explain that relative subrepository paths are made absolute before
rewrite rules are applied.
I sometimes look at a piece of software and if the man page says
"Copyright 2004", then I'm inclined to think that the project is stale
or that the authors are lazy. Neither is good publicity for us :-)
The original issue was something like:
$ hg init repo
$ cd repo
$ mkdir D
$ echo a > D/a
$ hg ci -Am adda
adding D/a
$ mv D temp
$ mv temp d
$ echo b > d/b
$ hg add d/b
adding D/b
$ hg ci -m addb
$ hg mv d/b d/c
moving D/b to d/c
$ hg st
A d/c
R D/b
Here we expected:
A D/c
R D/b
the logic being we try to preserve case of path components already known in the
dirstate. This is fixed by the current patch.
Note the following stories are not still not supported:
Changing directory case
$ hg mv D d
moving D/a to D/D/a
moving D/b to D/D/b
$ hg st
A D/D/a
A D/D/b
R D/a
R D/b
or:
$ hg mv D/* d
D/a: not overwriting - file exists
D/b: not overwriting - file exists
And if they were, there are probably similar issues with diffing/patching.
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).
