- use ctx.branch() instead of directly accessing the extra field "branch"
- move definitions of locals ('extra' and 'branch') down to where they
are used
This allows extensions that modify changeset metadata (e.g.
description) by overriding methods of changectx to get consistent
behavior from all log-like commands, regardless of whether templates
or styles are used. Without this, overriding changectx methods works
if you use styles or templates, but not with default log format.
This meant adding filectx.extra() for consistency with changectx.
This can be used for referring to revisions in a reasonable
meaningful, stable and monotonically increasing way, suitable for
releases or builds directly from a repository.
The latest tag is found by searching through untagged ancestors and
finding the latest tagged ancestor based on tag date. The distance is
found from the length of the longest path to the tagged revision.
For example:
hg log -l1 --template '{latesttag}+{latesttagdistance}\n'
can return
1.3.1+197
This is mostly work by Gilles Moris <gilles.moris@free.fr>
On Windows, Mercurial tries to glob expand provided filenames as a
convenience to the user. Unfortunately, there are valid filenames
which are not valid glob patterns. In those cases, we should fallback
to the original provided filename.
There is no standard python command to really detach a process under Windows.
Instead we use the low level API wrapped by subprocess module with all
necessary options to avoid any kind of context inheritance. Unfortunately, this
version still opens a new window for the child process.
The following have been tried:
- os.spawnv(os.P_NOWAIT): works but the child process is killed when parent
console terminates.
- os.spawnv(os.P_DETACH): works on python25, hang on python26 when writing to
the hgweb output socket.
- subprocess.CreateProcess() hack without shell mode: similar to
os.spawnv(os.P_DETACH).
Fix 1/3 for issue421
Semantically, it is better to use None over any other value when there is
"no value". Using maxint in this context is quite hackish, and is not forward
compatible.
Before this, to display file copies in templates, you had to write something
like {file_copies%filecopy}. For some reason, the {file_copy} subtemplate was
used by default but not defined by default in changeset_templater, while styles
were already using it. Here we define {file_copy} in changeset_templater, and
change the templater to handle formatting strings like {file_copies%filecopy}
with already expanded keys (in this case {file_copies}), for backward
compatibility.
{file_copies} template now displays file copies with or without the --copies
switch being set. A new {file_copies_switch} template implements the former
behaviour.
benchmarked with hg log -qf on the linux kernel:
before:
Time: real 39.010 secs (user 38.840+0.000 sys 0.060+0.000)
after:
Time: real 8.560 secs (user 8.440+0.000 sys 0.080+0.000)
benchmarked on crew repo with:
rm -rf * ; hg up -C ; for i in `find . -name "*.py"` ; do mv $i $i.new;done
followed by:
hg addremove -s 100
before: Time: real 28.890 secs (user 26.920+0.000 sys 1.450+0.000)
after : Time: real 6.790 secs (user 5.310+0.000 sys 1.350+0.000)
Getting the file from the working dir is less expensive than getting it from
the repo history, hence the speedup.
benchmarked on crew repo with:
rm -rf * ; hg up -C ; for i in `find . -name "*.py"` ; do mv $i $i.new;done
followed by:
hg addremove -s 100
before: Time: real 68.760 secs (user 65.760+0.000 sys 2.490+0.000)
after : Time: real 28.890 secs (user 26.920+0.000 sys 1.450+0.000)
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).
hg export -o outfile 1 2 3 4 had the same effect as hg -o outfile 4
This was caused by opening with 'w' instead of 'a'. This only occurs when
the filename pattern resulted in ambiguous patch filenames.
This fixes problems mentioned in issue660 comments (unrelated to original
issue) where directory was renamed, and symlink was added instead.
In such situation addremove wasn't able to correctly detect that old files
no longer here, but tried to add symlink (and failed due collision with
old files).
commit (aborts _after_ typing in a commit message)
backout (aborted after the initial revert)
tag (edited .hgtags and couldn't commit)
import (patch applied, then commit fails)
qnew (aborts on bad dates, but writes any valid date into the # Date header)
qrefresh (like qnew)
sign (like tag)
fetch (merge, merge, merge, merge, abort)
Previous implementation was passing (date + "to" + date), which fails
when "<" and friends are prepended to the date specifier.
Signed-off-by: Mark Williamson <mark.williamson@cl.cam.ac.uk>
- save dirstate lookup and exists check
- do all fs work inside a single dryrun clause
- move unlinking into inner copy section
- move target dir creation
- eliminate undelete mess
- fix a bug on mv a -> b -> a after merge
Allow adding to dirstate files that clash with previously existing
but marked for removal. Protect from reintroducing clashes by revert.
This change doesn't address related issues with update. Current
workaround is to do "clean" update by manually removing conflicting
files/dirs from working directory.
- move command dispatching functions from commands and cmdutil to dispatch
- change findcmd to take a table argument
- remove circular import of commands in cmdutil
- privatize helper functions in dispatch
Simply use find_exe('hg') as the default value for $HG and require to manually
set it if you have special requirements.
While the default will not always be 100% correct (i.e. the identical hg
version) for many users it is and for the others the hg executable found in
the PATH should do most things correctly.
Developers or other users with multiple installs can set $HG or run something
like util.set_hgexecutable in their shell or python scripts.
Additionally util.hgexecutable() is now available so extensions can access
the value with a public interface, too.
This fixes:
"hg -R" showing a useful error instead of traceback
"hg -R foo --repository bar" using bar instead of foo
And provides a way for other users of earlygetopt to accept more than
one value.
All current callers already pass in the repo root.
This normalizes things a bit. Now all repo types take a direct path to
repo root and only the command line interface (or the dispatcher)
searches from the current directory.
This allows us to use extensions specified in .hg/hgrc. Unfortunately,
this requires us to parse that file twice, but performance impact on
the version command appears to be less than 1%.
Every time util.pathto is called, we have to pass the repo root and the
repo cwd.
dirstate.pathto is a simple convenience function that knows about the
root and the cwd arguments. It's still possible to pass the cwd as an
optimization.
localrepo.pathto is a convenience function that just calls
dirstate.pathto, just like localrepo.getcwd.
dirstate.pathto becomes a single point that converts most (all?) paths
from the internal representation to some OS-specific relative path for
display purposes.
This allows you to do:
hg clone http://server/repo#stable
which is equivalent to:
hg clone -r stable http://server/repo
Future incoming, outgoing, and push commands will default to using
this id because it's recorded in the default path.
Other commands that accept URLs (push, pull, bundle, incoming, and
outgoing) also accept this syntax.
This will print a full hash node with --debug and a short one otherwise.
Use it with some default templates and in map-cmdline.default to print
the parents. This should fix issue538.
This makes its default behaviour useful again (issue108), and
changes it search the entire repository by default (instead
of just the cwd), just like all other commands.
It also hides issue204 by default, but you'll still see the
same behaviour if you give it a relpath: pattern.
The original code uses the similary score
1 - len(diff(after, before)) / len(after)
The diff can at most be the size of the 'before' file, so any small
'before' file would be considered very similar. Removing an empty file
would cause all files added in the same revision to be considered
copies of the removed file.
This changes the metric to
bytes_overlap(before, after) / len(before + after)
i.e. the actual percentage of bytes shared between the two files.
Add finddate to find the tipmost revision that matches a date spec
Add --date option to update
Add --date option to revert
Don't pass backout's -d option to revert
delete old uibuffer class
delete old stringio class
move show to _show
add new show that uses ui.pushbuffer to buffer
add new flush that writes buffered data
add props arg to changeset_printer to match _templater
rename commands.dodiff to patch.diff.
rename commands.doexport to patch.export.
move some functions from commands to new mercurial.cmdutil module.
turn list of diff options into mdiff.diffopts class.
patch.diff and patch.export now has clean api for call from 3rd party
python code.
