Right now, there are some situations in which localrepo.filecommit can
create filelog entries even though they're not needed. For example:
- permissions for a file have changed;
- qrefresh can create a filelog entry identical to its parent (see the
added test);
- convert-repo creates extra filelog entries in every merge where the
first parent has added files (for example, changeset ebebe9577a1a of
the kernel repo added extra filelog entries to files in the
arch/blackfin directory, even though the merge should only touch the
drivers/ata directory). This makes "hg log file" in a converted repo
less useful than it could be, since it may mention many merges that
don't actually touch that specific file.
They all come from the same basic problem: localrepo.commit (through
filecommit) creates new filelog entries for all files passed to it
(except for some cases during a merge).
Patch and test case provided by Benoit.
This should fix issue351.
These changes don't actually need a new filelog entry (see next patch),
but if we don't mention the files in the changelog, it becomes much
harder to find all changesets that touch a file (not even a
"hg log --removed file" will work).
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.
Rationale for not aborting instead:
The first parent is usually more important as it is the local branch
during a merge and commands like 'hg diff' and 'hg diff -r.' behave still
identically (except for the warning of course).
Added a test for log -r. with one and two parents.
The interface provided by opener(atomic=True) is inherently unsafe:
if an exception is raised in the code using the atomic file, the
possibly incomplete file will be renamed to its final destination,
defeating the whole purpose of atomic files.
To get around this, we would either need some bad hacks involving
sys.exc_info (to make sure things work in except: blocks), or an
interface to say "file is complete; rename it".
This is the exact interface provided by atomictempfile. Since there
are no remaining users of the atomicfile class, just remove it.
Right now, to generate the manifest of the working dir, we have to
perform a full walk of the working dir, which will be very slow,
especially if we're interested in only a small part of it.
Since we use the manifest only to find out the mode of files for git
patches, manually build an execf function to do it.
This should fix issue567.
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.
Uses the remote repository's lookup method as pull does and only transfers
what is needed to calculate incoming changesets.
One minor problem:
As only the needed changesets are transfered and stored in a local bundle
repository, the tip tag of this bundle is shows despite not being the tip
changeset of the remote repository.
(see "+tag: tip" in tests/test-incoming-outgoing.out in this patch)
The behaviour of find_in_path was broken for config options containing
path names, because it always searched the given path, even when not
necessary. The find_exe function is more polite: if the name passed
to it contains a path component, it just returns it.
In cdc7e3627e1b, Benoit made a change that substantially slows matching
when a big .hgignore file is in play, because it calls into the regexp
matching engine potentially hundreds of times per file to be matched.
I've partly rolled back his change, so that we only call into the matcher
once per file, but preserved the ability to report a meaningful error
message if there's a syntax error in the regexp.
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.
Right now, surprisingly enough, if you request an atomic file but the
file still doesn't exist, you get a regular file. AFAICS, the only time
this happens is during the initial creation of the dirstate.
We use the _wsgirequest object itself as the output file object.
To avoid a "self.out = self" which would create another circular
reference, we make the "out" attribute a trivial property.
The problem were some functions passed in the "defaults" argument
during the templater creation which use "self.t" directly. This
creates the cycle:
hgweb object
-> templater object
-> defaults dict
-> footer function
-> hgweb object
Instead of completely avoding the cycle, we break it after using
the templater.
The main problem was that dirstate.getcwd() returned just "",
which was interpreted as "we're at the repo root". It now returns
an absolute path.
The util.pathto function was also changed to deal with the "cwd is
an absolute path" case.
This allows the client to display a reasonable message to the user
(e.g. "Permission denied: .hg/lock"), instead of the current
"<url> does not appear to be an hg repository".
With this change, you have to use "hg locate 'hgweb/**'" to locate
all the files in directories named hgweb. OTOH, "hg locate '*l'"
will locate only files that end with "l" - e.g. a file called "hg.py"
will not be matched just because it's in a directory whose name ends
with "l" (e.g. "mercurial").
With that changeset, it's impossible to use a glob: pattern to match
e.g. all files ending in .py - glob:**.py would also match all files
in a directory called dir.py.
This makes the behaviour of glob: patterns more consistent:
hg status glob:dir and hg status -I glob:dir will match
the same files.
It's also consistent with the fact that {rel,}path patterns
recursively match the contents of a directory.
This will trigger every time somebody runs something like "hg diff"
or "hg status" without any arguments.
The important part here is returning util.always as the match function,
which is a much simpler (and faster) function than the usual return
value, and allows other code to just skip the filtering if it knows
all files will match.
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.
This removes a hack where we appended '/' to a dirname so that:
- it would not appear on the "dc" dict
- it would always be matched by the match function
This was a contorted way of checking if the directory was matched by
some hgignore pattern, and it would still fail with some uses of
--include/--exclude patterns.
Things would still work fine if we removed the check altogether and
just appended things to "work" directly, but then we would end up
walking ignored directories too, which could be quite a bit of work.
This allows further simplification of the match function returned by
util._matcher, and fixes walking the working directory with a
--include pattern that matches only the end of a name.
This should fix issue347.
It also highlights one issue with the directory walking code when
you have an --include pattern that matches the end of a filename.
This is fixed by the next patch.
names=['.'] means "include (recursively) only files from the current subdir";
the function then did a hack to walk the whole tree. Clean that up.
This also fixes a problem where "--include ." works in a subdir, but not
on the tree root.
