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%.
In python 2.4+ on darwin, locale.getpreferredencoding() returns
mac-roman regardless of what LC_CTYPE, LANG etc are set to. This can
produce hard-to-notice conversion errors if input text is not in
mac-roman. So this patch overrides it with setlocale/getlocale if the
environment has been customized, on the assumption that the user has
done so deliberately.
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.
