amend: fix copy records handling (
issue3410)
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>
test-commit-amend: exhibit an --amend weirdness
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.
localrepo: add setparents() to adjust dirstate copies (
issue3407)
The fix introduced in
eab9119c5dee 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.
test-rebase-parameters: more tests for revset/opts
- --source and revset
- --base and revset
- --rev and revset
- --rev and --source combination
- --rev and --base combination
help/config: expand [subpaths] help
Brifly explain why rewriting subrepository paths can be necessary.
Explain that relative subrepository paths are made absolute before
rewrite rules are applied.
doc: update copyright years to 2012
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 :-)