--flag foo uses:
[PATCH foo]
or
[PATCH M of N foo]
depending on the number of patches.
Multiple flags are supported: --flag foo --flag bar gives [PATCH foo bar]
When setting the date with qrefresh (-d|-D), and the patch does have
neither a 'Date:' nor a '# Date' header, add the date field as such:
- if the patch has a 'From:' header, add a 'Date:' header
- otherwise, upgrade to Mercurial extended patch format and add '# Date'
When setting the author field with qrefresh (-u|-U), and the patch does have
neither a 'From:' nor a '# User' header, add the author name as such:
- if the patch has a 'Date:' header, add a 'From:' header
- otherwise, upgrade to Mercurial extended patch format and add # From
The vast majority* of them are formatted like this in the source, so
this basically reverts the output to how it looked before we got the
minirst parser.
*: the help on templating use four spaces for some examples and will
now shown with an indentation of just two spaces.
Using the one true canonical path of a directory entry allows
equivalent paths to be treated gracefully. Equivalent means, in this
case, differing directory entries resulting in the same, unique file
system link to a file.
- modify _readtagcache() and _writetagcache() to read/write tag->node
mapping for global tags
- if (and only if) tip unchanged, use that cached mapping to avoid
reading any revisions of .hgtags
- change so tag names are UTF-8 in memory in tags.py, and converted to
local encoding as late as possible (in localrepository._findtags())
- rename findglobaltags() to findglobaltags1() (so the "no cache"
implementation is still there if we need it)
- add findglobaltags2() and make findglobaltags() an alias for it
(disabling tag caching is a one-line patch)
- factor out tagcache class with methods readcache() and writecache();
the expensive part of tag finding (iterate over heads and find
.hgtags filenode) is now in tagcache.readcache()
- give detailed dumps of .hgtags and localtags content
- repeat some query operations to expose cache bugs
- ensure that rollback/strip undo tagging operations
- use simpler way ('hg id') to get current changeset id
- add 'echo' statements to guide the eye when reading output
- add some more output to clarify the state of .hgtags
- drop '-d' option from every commit/tag, since run-tests.py
does this (although with a different timestamp, so changeset
ids differ)
The biggest problem was the data structure, which did not allow changing
a file into a directory or vice versa. This problem is fixed by 47d29dcb7266.
The walk() method also had an issue in this case:
- we know 'path' as a directory. inotify server sleeps.
- 'path' is deleted
- 'path' is recreated as a file
- the server catches up here, and see the deletion. it instantiates a scan(),
which in its turn calls for walk(repo, path).
- walk() then assumes that 'path' is a directory and calls os.listdir on it,
which raises an OSError(errno.ENOTDIR)
Catch the error, and yield the file instead of the directory contents.
When navigating through a patch series by qpushing and qpopping it was easy to
get lost because qpop was silent. I found myself often running qnext after qpop
to see which patch I just dropped - especially if I was about to qrm it. This
patch makes qpop more symmetric to qpush by showing which patches are
applied/"unapplied".
I think it is a good change even though it changes output by adding a new line
of output.
The sort modes flags and convert.cvsps options were indented while the
convert.hg, convert.svn, and convert.p4 options were not. I've now
un-indented all of them.
We have always had a left margin of 4 characters -- probably just
because that's how docstrings for top-level functions turn out by
default, but it also looks nice in the built-in help.
The docstrings were wrapped at 70 characters, which is the default for
Emacs. However, this gives a right margin of 10 characters in a
standard 80 character terminal.
I've now wrapped the relevant docstrings at 78 characters, effectively
killing the right margin. The asymmetric margins looked a bit odd and
some of the text looked cramped with a right margin, so Dirkjan and I
felt that it was best to remove it entirely. The two character gap was
kept to have some space between the border of the terminal -- it will
also make diffs involving the docstrings fit in a 80 character line.
Localized date in the From_ prevents MUAs like mutt from parsing mbox files
generated by patchbomb. Using a 24 characters date in asctime format instead.
Adds a test for python hooks configured with python:[file]:[hook] syntax
in .hgrc. Increases the test coverage for mercurial/hook from 92% (79/85)
to 96% (82/85).
For example, given 1 (branch a) -> 2 (branch b) -> 3 (branch a)
I expect "hg heads a" to show only 3.
Discovered by running hg heads HEAD on the mutt repo, where older clients
committed default on top of HEAD.
- just use "files" instead of "filenames" (analogous to "hg status -h")
- reference the extension help wrt pattern configuration
Kudos to timeless for helpful suggestions.
ui.prompt was completely silent in non-interactive mode, unless in verbose
mode. It is fine that it chooses the default automatically, but it is confusing
that the message and prompt shown interactively can't be found in scripted
tests.
The prompt and selection is now .write'ed instead of .note'ed.
The code for wrapping a single line of text with a hanging indent was
duplicated in commands and help -- it's now moved to a new function
called wrap in util.
The function defaults to a line width is 78 chars, and this un-wraps
some command line flag descriptions, hence the test output changes.
This command does exactly what 'hg remove -Af [FILES]' does.
The reason for creating a new command is that the options for 'hg remove'
are confusing (-A removes only deleted files, -f forces deletion, and using
both means *the exact opposite of both*).
[mpm: simplified help text, code, and updated tests]
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
Add a --closed (-c) option to 'hg heads' to show all heads and change the
default behavior to refrain from showing fully closed branches.
Enhance 'hg heads <branch>' so that:
* default: displays normal & inactive heads, not closed heads
* --closed: displays normal, inactive & closed heads
* --active: displays only normal heads
* both --closed and --active: displays normal & closed heads only
The heads(...) and branchheads(...) functions will now only return closed
heads when explicitly asked for them. This will cause 'hg merge' to have
better behavior in the presence of a branch that has closed heads when no
explicit rev is passed.
(Needed at least for Subversion bindings on OS X, which are in
/opt/subversion. Useful for other external libraries installed in
non-standard places too.)
- in parseargs(), check that --with-hg value is valid
- add handy --local option for "--with-hg=../hg"
- ensure that we always set PATH and PYTHONPATH (not just
when doing a temporary install)
- override any existing PYTHONPATH, so test success does not
depend on whatever happens to be in the caller's environment
- give tests a little more control by exporting $PYTHON to the
environment; needed by test-convert and test-mergetool when
they run hg with a stripped-down $PATH
Also, add a big comment explaining all the corner cases to test for the
next person who tries to modify this script.
- rename _hgpath() to _gethgpath() and move it down next to _checkhglib()
- change _gethgpath() so it caches its result: replaces global 'hgpkg'
that anyone can use with global '_hgpath' that is only for _gethgpath()
- no need to pass 'expecthg' to runchildren() or runtests() anymore
Also: do not change global PYTHON when doing coverage; this seems to
be unnecessary, since we create a dummy 'hg' script that handles
coverage for us, and it made things brittle. (E.g. the rest of this
patch makes the call to _hgpath() come later, and it was broken by
enabling coverage.)
(Extremely handy when you break parallel operation and need to figure
out what's going on. The assumption is that if you run with -v, you
want more details.)
This error trigger if one calls bundle with the wrong parameters and
it is thus not an error scripts will want to look for (they could and
should ensure that they call bundle with the correct parameters).
The fstat function was undefined, but never used since a stat object
was always passed in the optional st argument. Passing st is now
mandatory.
This bug crept in when util was split up into posix and windows
modules. The fstat function is still defined in util, but importing it
into posix would create an import cycle which seems unnecessary.
Using '-r null' instead of '-v' as the overriden command default.
The latter did not have any effect on output, thus not giving much
indication on whether the modified defaults were really in use or not.
Each named branch is considered separately, and the push is allowed if
no new branch heads are created for any named branch to be pushed.
Due to some tests's use of --debug, their output will change after this
addition. This has been fixed as well.
Co-contributor: Henrik Stuart <henrik.stuart@edlund.dk>
The repository command, 'branchmap', returns a dictionary, branchname
-> [branchheads], and will be implemented for localrepo, httprepo and
sshrepo.
The following wire format is used for returning data:
branchname1 branch1head2 branch1head2 ...
branchname2 ...
...
Branch names are URL encoded to escape white space, and branch heads
are sent as hex encoded node ids. All branches and all their heads are
sent.
The background and motivation for this command is the desire for a
richer named branch semantics when pushing changesets. The details are
explained in the original proposal which is included below.
1. BACKGROUND
The algorithm currently implemented in Mercurial only considers the
graph theoretical heads when determining whether new heads are
created, rather than using the branch heads as a count (the algorithm
considers a branch head effectively closed when it is merged into
another branch or a new named branch is started from that point
onward).
Our particular problem with the algorithm is that we'd like to see the
following case working without forcing a push:
Upsteam has:
(0:dev) ---- (1:dev)
\
`--- (2:stable)
Someone merges stable into dev:
(0:dev) ---- (1:dev) ------(3:dev)
\ /
`--- (2:stable) --------´
This can be pushed without --force (as it should).
Now someone else does some coding on stable (a bug fix, say):
(0:dev) ---- (1:dev) ------(3:dev)
\ /
`--- (2:stable) ---------´---------(4:stable)
This time we need --force to push.
We allow this to be pushed without using --force by getting all the
remote branch heads (by extending the wire protocol with a new
function).
We would, furthermore, also prefer if it is impossible to push a new
branch without --force (or a later --newbranch option so --force isn't
shoe-horned into too many disparate functions, if need be), except of
course in the case where the remote repository is empty.
This is what our patches accomplish.
2. ALTERNATIVES
We have, of course, considered some alternatives to reconstructing
enough information to decide whether we are creating new remote branch
heads, before we added the new wire protocol command.
2.1. LOOKUP ON REMOTE
The main alternative is to use the information from remote.heads() and
remote.lookup() to try to reconstruct enough graph information to
decide whether we are creating new heads. This is not adequate as
illustrated below.
Remember that each lookup is typically a request-response pair over
SSH or HTTP(S).
If we have a simple repository at the remote end like this:
(0:dev) ---- (1:dev) ---- (3:stable)
\
`--- (2:dev)
then remote.heads() will yield [2, 3]. Assume we have nodes [0, 1, 2]
locally and want to create a new node, 4:dev, as a descendant from
(1:dev), which should be OK as 1:dev is a branch head.
If we do remote.lookup('dev') we will get [2]. Thus, we can get
information about whether a branch exists on the remote server or not,
but this does not solve our problem of figuring out whether we are
creating new heads or not.
Pushing 4:dev ought to be OK, since after the push, we still only have
two heads on branch a.
Using remote.lookup() and remote.heads() is thus not adequate to
consistently decide whether we are creating new remote heads (e.g. in
this situation the latter would never return 1:dev).
2.2. USING INCOMING TO RECONSTRUCT THE GRAPH
An alternative would be to use information equivalent to hg incoming
to get the full remote graph in addition to the local graph.
To do this, we would have to get a changegroup(subset) bundle
representing the remote end (which may be a substantial amount of
data), getting the branch heads from an instantiated bundlerepository,
deleting the bundle, and finally, we can compute the prepush logic.
While this is backwards compatible, it will cause a possibly
substantial slowdown of the push command as it first needs to pull in
all changes.
3. FURTHER ARGUMENTS IN FAVOUR OF THE BRANCHMAP WIRE-PROTOCOL EXTENSION
Currently, the commands incoming and pull, work based on the tip of a
given branch if used with "-r branchname", making it hard to get all
revisions of a certain branch only (if it has multiple heads). This
can be solved by requesting the remote's branchheads and letting the
revisions to be used with the command be these heads. This can be done
by extending the commands with a new option, e.g.:
hg pull -b branchname
which will be turned into the equivalent of:
hg pull -r branchhead1 -r branchhead2 -r branchhead3
We have a simple follow-up patch that can do this ready as well
(although not submitted yet as it is pending the acceptance of the
branch patch).
4. WRAP-UP
We generally find that the branchmap wire protocol extension can
provide better named branch support to Mercurial. Currently, some
things, like the initial push scenario in this mail, are fairly
counter-intuitive, and the more often you have to force push, the more
it is likely you will get a lot of spurious and unnecessary merge
nodes. Also, restricting incoming and pull to all changes on a branch
rather than changes on the tip-most head would be a sensible extension
to making named branches a first class citizen in Mercurial.
Currently, named branches sometimes feel like a late-coming unwanted
step-child.
We have run it in a production environment for a while, with fewer
multiple heads occurring in our repositories and fewer confused users
as a result.
Also, it fixes the long-standing issue 736.
Co-contributor: Sune Foldager <cryo@cyanite.org>
the escaping of directories ending with .i or .d doesn't
really belong to filelog.
we put the encoding/decoding in store instead, for backwards
compat, streamclone and the fncache file format still uses the
partially encoded filenames.
Before this patch, the only way to get hgwebdir to honor the recursive paths
was to create a config object or a config file with the recursive paths in it.
This patch makes hgwebdir treat paths the same whether passed in as a list,
tuple, config or however hgwebdir supports passing paths.
When specifying --in-reply-to for a message M, have
[M]
[0/2]
[1/2]
[2/2]
instead of
[M]
[0/2]
[1/2]
[2/2]
which is more consistent with the way messages are being threaded
when --in-reply-to is not used.
The commit editor is now invoked before files and manifest are
committed. The editor is now run with only the wlock held and aborting
an edit no longer requires rolling back a transaction. Changes to
files during a commit still result in undefined behavior.
(This is preliminary work for committing subrepositories)
The display used to jump up and down when switching from the file view
to the annotate view. It now stays still: when switching from the file
view to the annotate view it looks like the file content is simply
right-shifted to make room for the author names.
Instead of only finding similarities in the added/removed files found
by the addremove step, follow the match object:
hg addremove -s80 foo -> add and removes files in foo
+ find similarities between files in foo
hg addremove -s80 -> add and removes files in the whole repo
+ find similarities between files in the whole repo
hg import --similarity will still work correctly (only find similarities
between files found in the patch).
The test copied get-with-headers.py from $TESTDIR and committed it to
a test repository. The test output therefore depended unnecessarily on
the exact content of get-with-headers.py. It has now been replaced
with another small Python script.
An empty username or a username with a "\n" will make the revision
text contain two "\n\n" sequences -> corrupt repository.
The problem is that changelog.read expects to find exactly one "\n\n"
separator and thus cannot unpack the revision.
When cloning with the -r option or # url format from a tag the destination
repo most likely won't have the tag. We can save the lookup result to get to
the correct parent anyway. Similar to issue1306, but for tags.
