Previously, branch names were ideally manipulated as UTF-8 strings,
because they were stored as UTF-8 in the dirstate and the changelog
and could not be safely converted to the local encoding and back.
However, only about 80% of branch name code was actually using the
right encoding conventions. This patch uses the localstr addition to
allow working on branch names as local strings, which simplifies
handling so that the previously incorrect code becomes correct.
Without specifying the parent revision of the working copy, users will
update to tip, which is most likely the other head they were trying to
merge, not the revision they were at before the merge.
This is a revert of f6aa66376f81. The "bug" mentioned in this changeset is unclear:
hopefully using a test to cover this usage should prevent any bugs.
Since d6ca622d1122 the branch argument for addbranchrevs should be a tuple:
(hashbranch, branches)
The right empty value therefore is (None, []) instead of None.
Previously #foo and --branch foo were handled identically.
The behavior of #foo hasn't changed, but --branch now works like this:
1) If branchmap is not supported on the remote, the operation fails.
2) If branch is '.', substitute with branch of the working dir parent.
3) If branch exists remotely, its heads are expanded.
4) Otherwise, the operation fails.
Tests have been added for the new cases.
When trying to do hardlink-cloning, the os_link() call of the
first file tried already fails on Windows, if the source is on a
UNC path.
This change avoids calling os_link() for the rest of files, leaving
us with a *single* failed os_link() call per clone operation, if the
source can't do hardlinks.
When trying to do hardlink-cloning, the os_link() call of the
first file tried already fails on Windows, if the source is on a
UNC path.
This change avoids calling os_link() for the rest of files, leaving
us with a *single* failed os_link() call per clone operation, if the
source can't do hardlinks.
This avoids problem with unexpanded paths when it's not possible to
expand it at higher level (for example, if file:~/path/ is supplied as
path in schemes).
Previously, the name part of an repo#name url was interpreted as a
revision, similar to using the --rev option. Now it is instead looked
up as a branch first, and if that succeeds all the heads of the branch
will be processed instead of just its tip-most head. If the branch
lookup fails, it will be assumed to be an revision as before (e.g. for
tags).
Combining translated string fragments into bigger strings is bad
practice because it removes context from the fragments. The translator
sees the fragments in isolation and might not jump back to the source
to see how a string like "%d files %s" is actually used.
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.
In many places hg.parseurl is called with a url and "opts.get('rev')",
suggesting the second, optional argument can be None. Because opts['rev']
usually defaults to [] this never happens in practice.
However, extensions don't necessarily behave the same, but do copy this
pattern.
Also, include wider hg.parseurl tests, beyond a demonstration of the problem.
If the user created the clone target directory before running
the clone command, only cleanup the .hg/ repository when errors
occur. Leave the empty target directory in place.
With this change, "hg clone" looks like this:
% hg clone http://example.com/repo/big big
requesting all changes
adding changesets
adding manifests
adding file changes
added XXX changesets with XXX changes to XXX files
updating working directory
XXX files updated, XXX files merged, XXX files removed, XXX files unresolved
So the user sees
% hg clone http://example.com/repo/big big
requesting all changes
adding changesets
adding manifests
adding file changes
added XXX changesets with XXX changes to XXX files
updating working directory
while Mercurial is writing to disk to populate the working directory
With this change, "hg clone" looks like this:
% hg clone big big-work
updating working directory
XXX files updated, XXX files merged, XXX files removed, XXX files unresolved
A new function (extensions.extensions) allows the code that is
interested in those attributes to handle them directly.
This allows some cleanups of extensions.py. Notably, we can
remove the extensions.commandtable hack.
It also makes it easier to add standard extension attributes,
like a "hgwebsetup" function or a "helptable" dict that augments
the data in help.py, etc.
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.
The ui object we received in this function may belong to another repo,
which could be confusing from the hook point of view. Trying to use
the ui object from the newly created repo should avoid this confusion.
since creating a repo raises an exception if the repo already
exists, there's no need to try to create one.
add some test for repo creation when the destination exists
islocal tells if a repo or url is local.
defaultdest returns default path for clone if explicit path not given.
clone can now take repo or url as source
existing clone code uses pull to get changes from remote repo. is very
slow, uses lots of memory and cpu.
new clone code has server write file data straight to client, client
writes file data straight to disk. memory and cpu used are very low,
clone is much faster over lan.
new client can still clone with pull, can still clone from older servers.
new server can still serve older clients.
str.find return -1 when the substring is not found, -1 evaluate
to True and is a valid index, which can lead to bugs.
Using alternatives when possible makes the code clearer and less
prone to bugs. (and __contains__ is faster in microbenchmarks)
Rearranged the clone command a good bit to make sure it validates that
the source does exist and that the destination doesn't before doing anything.
Before I moved the source repo check it would create the destination
repository before it verified the source existed.
Moved the responsibility for creating the destination repo root directory
entirly into the localrepo class so that local to local cloning doesn't break.
This also simplifies the code a bit since it's no longer being done in both
clone and init.
Changed the names of the 'repo' and 'other' variables to 'dest_repo' and
'src_repo' to maintain my sanity.
Passes 82/83 tests. The only failure is the version number test, which I
suspect is supposed to fail since it comes from a generated file.
- create new statichttprepo class
- pull remote bits out of localrepo
- pull remote bits out of util.opener
- switch hg.repository to use statichttprepo
TAH found a bug where push would push things the remote already had,
raising an assertion. This turned out to be because the changeset
protocol was not recording a common subset node in one case.
Also discovered was that the protocol was queueing multiple copies of
a node for pull. Fixed by changing fetch to a hash.
Add some more debugging output.
- rename mode to branch_merge
- use explicit update mode
- use negative mtime for updates that set mtime
- expand some cryptic variable names
- elaborate merge dirstate comments
- remove redundant manifest lookup for non-merge case
- remove impossible merge case
- fix up test cases
- use new changed list to track what files actually got new revlog entries
at commit/rawcommit time
- when updating a file during a merge, don't mark it as completely unchanged
- handle file not being in parent 1 in status
Since switching to the multihead approach, we've been creating
excessive file-level merges where files are marked as merged with
their ancestors.
This explicitly checks at commit time whether the two parent versions
are linearly related, and if so, reduces the file check-in to a
non-merge. Then the file is compared against the remaining parent,
and, if equal, skips check-in of that file (as it's not changed).
Since we're not checking in all files that were different between
versions, we no longer need to mark so many files for merge. This
removes most of the 'm' state marking as well.
Finally, it is possible to do a tree-level merge with no file-level
changes. This will happen if one user changes file A and another
changes file B. Thus, if we have have two parents, we allow commit to
proceed even if there are no file-level changes.
Right now, mercurial doesn't take daylight saving time into account
because it uses time.timezone inconditionally, instead of resorting to
time.altzone if daylight saving time is on.
named branching is when you identify a head by a tag on an earlier revision.
This patch adds repo.branchlookup for searching through the tree to
find branch tags for heads.
hg update -b tag is added to checkout based on branch tags
hg heads -b is added to print the tag associated with each head
Prior to this, a file that did not exist was reported as showing up in
the filesystem, as were files of unsupported types (such as fifos).
Now, an error message is printed and nothing is returned in such cases.
This change also moves the commands.pathto function to the util module,
as the walk code needs it to print non-confusing error messages.
The repo walking code introduces a number of calls to dirstate.map.copy(),
significantly slowing down the walk on large trees. When a list of
files is passed to the walking code, we should only look at map entries
relevant to the file list passed in.
dirstate.filterfiles() is added to return a subset of the dirstate map.
The subset includes in files passed in, and if one of the files requested
is actually a directory, it includes any files inside that directory tree.
This brings the time for hg diff Makefile down from 1.7s to .3s on
a linux kernel repo.
Also, the diff command was unconditionally calling makewalk, leading
to an extra pass through repo.changes. This patch avoids the call
to makewalk when commands.diff isn't given a list of patterns, cutting
the time for hg diff (with no args) in half.
Index: mine/mercurial/hg.py
===================================================================
The dirstate has to match what is in the repository (what would be
checked out with 'hg update -C'), because the resulting file may be
identical to the new parent, or it may be completely different.
Previously the dirstate wasn't updated, so if you changed the file to
look like the original parent, it might be considered unmodified
relative to the new parent.
On the other OS, it seems that case insensitivity for
environment vars can bite users when using some unknown
combination of python 2.4.1 and win2kSP4+minsys (and
probably other vversions of these softwares).
The best way to avoid problems in those weird cases is to
ignore OSError exception during env var deletion.
Interface is not yet changed.
Non-regular files are considered to be removed or deleted.
Removed the unneeded match(fn) call for adding to the unknown list.
The first consequence of this is that absolute and relative paths now
all work in the same way. The second is that paths that lie outside
the repository now cause an error to be reported, instead of something
arbitrary and expensive being done.
Internally, all of the serious work is in the util package. The new
canonpath function takes an arbitrary path and either returns a
canonical path or raises an error. Because it needs to know where the
repository root is, it must be fed a repository or dirstate object, which
has given commands.matchpats and friends a new parameter to pass along.
The util.matcher function uses this to canonicalise globs and relative
path names.
Meanwhile, I've moved the Abort exception from commands to util, and
killed off the redundant util.CommandError exception.
