Trying as much as possible to consistently:
- use a present tense predicate followed by a direct object
- verb referring directly to the functionality provided
(ie. not "add command that does this" but simple "do that")
- keep simple and to the point, leaving details for the long help
(width is tight, possibly even more so for translations)
Thanks to timeless, Martin Geisler, Rafael Villar Burke, Dan Villiom
Podlaski Christiansen and others for the helpful suggestions.
Currently listing non-enabled extensions and a short introductory text.
Thanks to Dan Villiom Podlaski Christiansen for the preliminary
proof-of-concept code for listing available extensions.
I found that typical case is that grep target is added at (*) revision
in the tree shown below.
+--- 1(*) --- 3
0
+--- 2 ------ 4
Now, I expect 'hg grep --all' to show only rev:1 which is first
appearance of target line.
But 'hg grep --all' will tell:
target line dis-appeared at 3 => 4
target line appeared at 2 => 3
target line dis-appeared at 1 => 2
target line appeared at 0 => 1
because current 'hg grep' implementation compares not between target
revision and its parent, but between neighbor revisions in walkthrough
order.
I checked performance of this patch by "hg grep --follow --all
walkchangerevs" on whole Mercurial repo, and patched version could
complete as fast as un-patched one.
Convert now handles errors from p4 during conversion more gracefully.
If keyword expansion is enabled in a P4 file then keywords will be
unexpanded in hg.
Added testcase for p4 filetypes and keyword (un)expansion.
This testcase ignores UTF and Apple files to avoid binary data.
Edited by pmezard: fixed collation issue on OSX
Specifically, always run 'cvs commit' with -f option to force commit;
add one strategic sleep which seems to be necessary for post-merge
clobber-and-commit (-f doesn't force a commit there?).
- factor out cvsci function (similar to other test-convert-cvs* scripts)
- add filterpath function (also similar to other scripts)
- generally munge the output of CVS
- add lots of output to make it easier to follow when things go wrong
This doesn't make the test pass reliably under CVS 1.11; it just makes
it behave the same as under CVS 1.12, i.e. sometimes it passes and
sometimes it fails. Failure is more frequent with faster hardware.
- rename test-convert-cvs-builtincvsps-cvsnt-mergepoints
(and related files) to test-convert-cvsnt-mergepoints
- this ensures that the test will be run, but does NOT make
it pass: in particularly, it fails regularly for me due
to the inconsistent behaviour of CVS itself
- expect "Branchpoints:" in debugcvsps output
The intent is to fix many issues involving patching when win32ext is enabled.
With win32ext, the working directory and repository files EOLs are not the same
which means that patches made on a non-win32ext host do not apply cleanly
because of EOLs discrepancies. A theorically correct approach would be
transform either the patched file or the patch content with the
encoding/decoding filters used by win32ext. This solution is tricky to
implement and invasive, instead we prefer to address the win32ext case, by
offering a way to ignore input EOLs when patching and rewriting them when
saving the patched result.
- repository heads are not associated with the closed attribute, so
remove it making the code in line with the concept.
- Fix functions that were calling heads with the parameter.
- Adjust webcommands.branches to include the concept of inactive
as well as open and closed branches
- Fix code and docstrings in commands to make the correct use of
closed branches & branch heads clearer
- Improve grammar of 'hg heads' help text (2nd submission)
this does not alter the cli for hg branches, that work is
still to be done
This records the branches starting at individual CVS file revisions,
using the symbolic names map rather than just the branches
information. This information is used to generate Mercurial
changesets. Despite the changes, the CVS conversion still suffers
heavily from cvsps' deficiencies in generating a correct
representation of the CVS repository history.
New behavior is generally superior and more correct, except possibly
with regards to missing files. hg up . is now effectively a no-op,
which is probably the desired behavior for people expecting to move to
tip, but may surprise people who were expecting deleted files to
reappear.
case 1: update to .
a-w -> a-w
classic: ancestor a
missing recreated right?
rmed recreated WRONG
added forgotten WRONG
changed preserved RIGHT
conflicted can't happen
backward merge: ancestor a (NO EFFECT)
missing missing wrong?
rm'ed rm'ed RIGHT
added preserved RIGHT
changed preserved RIGHT
conflicted can't happen
case 2: update to ancestor of .
a-b-w -> b-w
\
a
classic: ancestor a
missing recreated right?
rmed recreated wrong?
added forgotten wrong?
changed preserved RIGHT
conflicted preserved wrong?
backwards merge: ancestor b
missing missing or conflict right?
rm'ed missing or conflict right?
changed preserved RIGHT
conflicted merge RIGHT
added preserved right?
Different platforms implement -R differently (and it produces
unneccessarily verbose output in this case). find is just as
good and more consistent. Unbreaks test on OpenBSD.
Edited by pmezard: added 'sort' call
