- Add patchmeta.copy() and emit copies from iterhunks. Modifying patchmeta
instances in applydiff() makes things simpler.
- Rename selectfile() into makepatchmeta(). It is responsible for creating
patchmeta for regular patches.
- Pass patchmeta objects to patchfile() directly
patchmeta instances were associated with git patches, for regular patches we
had to pass additional variables to tell the patch intent to patchfile().
Instead, we generate patchmeta for regular patches and pass them. This will
also help with patch filtering by matcher objects.
since it's possible to reuse the ui object (see 6772a32edec7)
between dispatch calls, the ui might have been wrapped already.
we could probably move this test up a bit but leaving it here
allows updates to take effect by extstyles() and configstyles().
Also restructures the mode determination as discussed on IRC.
I tried to simplify the code too, while keeping the original
semantics except for the case of --color=always.
The internal list representation of guards was leaking into the
output. The guards were always printed using repr(guard) and that
style was kept.
When "hg qguard -l" prints several guards for a patch, it does so by
joining the names with " " and that style was used for the error
messages too.
git patches may require copies to be handled out-of-order. For instance, take
the following sequence:
* modify a
* copy a into b
Here, we have to generate b from a before its modification. To do so,
applydiff() was scanning for copy metadata and performing the copies before
processing the other changes in-order. While smart and efficient, this approach
complicates things by handling file copies and file creations at different
places and times. While a new file must not exist before being patched a copied
file already exists before applying the first hunk.
Instead of copying the files at their final destination before patching, we
store them in a temporary file location and retrieve them when patching. The
filestore always stores file content in real files but nothing prevents adding
a cache layer. The filestore class was kept separate from fsbackend for at
least two reasons:
- This class is likely to be reused as a temporary result store for a future
repository patching call (entries just have to be extended to contain copy
sources).
- Delegating this role to backends might be more efficient in a repository
backend case: the source files are already available in the repository itself
and do not need to be copied again. It also means that third-parties backend
would have to implement two other methods. If we ever decide to merge the
filestore feature into backend, a minimalistic approach would be to compose
with filestore directly. Keep in mind this copy overhead only applies for
copy/rename sources, and may even be reduced to copy sources which have to
handled ahead of time.
The patcher has to know if a file is being created or removed to check if the
target already exists, or to actually unlink the file when a hunk emptying it
is applied. This was done by embedding the creation/removal information in the
first (and only) hunk attached to the file.
There are two problems with this approach:
- creation/removal is really a property of the file being patched and not its
hunk.
- for regular patches, file creation cannot be deduced at parsing time: there
are case where the *stripped* file paths must be compared. Modifying hunks
after their creation is clumsy and prevent further refactorings related to
copies handling.
Instead, we delegate this job to selectfile() which has all the relevant
information, and remove the hunk createfile() and rmfile() methods.
It has substantially different semantics from forget at the command
layer, so change it to avoid confusion.
We can't simply combine it with remove because we need to explicitly
drop non-added files in some cases like commit.
Also, don't create a backup dir if we have no files to backup.
This is essential for qrefresh --interactive. Since we can't
select individual files to qrefresh without eliminating already
present changes, we have to backup all changes in the working
copy to avoid refreshing unaccepted hunks.
(thanks to Patrick for the idea)
When trying to import a url that ends with a slash
os.path.basename() would return an empty string. So
when seeing a leading slash, remove it and infer the
patch name from the remaining url.
e.g. `hg qimport http://paste.pocoo.org/raw/xxx/`
deduced '.' to be the patch name. Now we'll deduce 'xxx'.
_updatedir() is no longer used by internalpatch()
The change in test-mq-missingfiles.t comes from workingbackend not considering
the missing 'b' file as changed, thus not calling addremove() on it.
Most filesystem calls are already isolated in patchfile but this is not enough:
renames are performed before patchfile is available and some chmod calls are
even done outside of the applydiff call. Once all these calls are extracted
into a backend class, we can provide cleaner APIs to write to a working
directory context directly into the repository.
The verb to allow requires a direct object.
Lintian, a Debian tool to find common mistakes, reported it. I'm not a
native english speaker but I think this is correct.
This is not enabled by default, but the user can add it by setting
progress.format.
We might want to let the estimate format output a speed instead of an
ETA if there is not total. Currently estimate just returns the empty
string in that case.
Zeroconf launches two threads in the background, and they wait on
Condition objects to exit. We need to call Zeroconf.close() to
release those conditions so that threads can gracefully exit.
This means that an interrupt on the hg process will now gracefully
propagate to the Zeroconf children, fixing that bug which did not
allow us to kill an `hg serve` process.
When converting directory additions/replacement with project directory set to
root, _iterfiles() sometimes returned paths starting with a slash making
following svn calls to fail.
I could not reproduce the issue with hand-crafted repositories.
Report and first analysis by Clinton Chau <clinton@clearcanvas.ca>
The win32text extension does not break eol or vice-versa, so it is not a fatal
error to have both of them enabled. It's just folly. So spewing warnings in
this condition is preferrable to aborting. When both extensions are enabled,
the user now sees:
% hg st
the eol extension is incompatible with the win32text extension
win32text is deprecated: http://mercurial.selenic.com/wiki/Win32TextExtension
M hgext/eol.py
This patch prevent mq to crash when .hg/patches/status contains Malformed lines
(without ":"). Blank lines are ignored and other malformed lines issue a
warning.
