The new registration of in-process data filters (introduced in
75177cef51d3 & 8c9fa240ac96) failed to correctly strip the filter name
from its arguments before passing the "command" to the filter
function. Thus a registration such as
[decode]
*.gz = compress: -9
would result in the associated filter function being called with the
argument 'compress: -9' rather than just '-9' as expected.
This should avoid a bad performance problem when the branch cache is
not up-to-date, and hgweb can't write an updated version because it
lacks permissions.
While some can function with just some text and an optional command name,
others may want a repository object, a ui object, and a file path.
Use the enhanced information to good effect in win32text.dumbdecode's warning.
- Changing data filters implementation is easier, adddatafilter() can rewrap
filter after inspecting their prototype
- Custom data filters really belongs to localrepo, mixing them with generic
wrapper like "pipefilter" or "tempfilter" looks wrong.
- util.filtertable should not be accessed from extensions
This will allow strip to include in the temporary changegroup some extra
file/manifest revisions that should be restored after the truncations.
This code doesn't allow specification of changelog nodes since I won't
need that right now, the code wouldn't be tested and it's probably
possible to do something similar enough by using the bases/heads
arguments.
- use "branch 'foo'" to distinguish from "branch merge".
- commit messags can be empty (to abort commits)
- Added value for editor message: Tell about HG: lines like CVS does.
If a file is edited between the time we record file states in the repo
and update the dirstate, that change can be lost to hg status. Because
we invoke the editor between these two points, that window can be
arbitrarily large.
This greatly shrinks the window by recording the commit change
immediately. If our checkin fails, we simply invalidate the dirstate.
- handle chunk headers separately rather than prepending them to
(potentially large) chunks
- break large chunks into 1M pieces for compression
- don't prepend file metadata onto (potentially large) file data
If the file was copied, we don't want to reuse the original entry.
I think this is mostly a theoretical issue - when there are copies,
fp1 == nullid, so it's very unlikely that the fl.cmp(fp1, t) would
think the file was unmodified. In any case, if there was a copy,
we should forcefully create a new entry.
After a hg merge, we want to include in the commit all the files that we
got from the second parent, so that we have the correct file-level
history. To make them visible to hg commit, we try to mark them as dirty.
Unfortunately, right now we can't really mark them as dirty[1] - the
best we can do is to mark them as needing a full comparison of their
contents, but they will still be considered clean if they happen to be
identical to the version in the first parent.
This changeset extends the dirstate format in a compatible way, so that
we can mark a file as dirty:
Right now we use a negative file size to indicate we don't have valid
stat data for this entry. In practice, this size is always -1.
This patch uses -2 to indicate that the entry is dirty. Older versions
of hg won't choke on this dirstate, but they may happily mark the file
as clean after a full comparison, destroying all of our hard work.
The patch adds a dirstate.normallookup method with the semantics of the
current normaldirty, and changes normaldirty to forcefully mark the
entry as dirty.
This should fix issue522.
[1] - well, we could put them in state 'm', but that state has a
different meaning.
The following properties of a path are now checked for:
- under top-level .hg
- starts at the root of a windows drive
- contains ".."
- traverses a symlink (e.g. a/symlink_here/b)
- inside a nested repository
If any of these is true, the path is rejected.
The check for traversing a symlink is arguably stricter than necessary;
perhaps we should be checking for symlinks that point outside the
repository.
This way rollbacks happen while the repo is still locked.
Deleting lock before wlock is not strictly necessary, but is
more consistent with the locking order.
