- Added files are never deleted (only removed with --force).
- Modified files can only be removed with --force.
- With --after, only deleted files are removed.
- With --after --force, all files are removed but not deleted.
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
This should fix the race where
hg commit foo
<change foo without changing its size>
happens in the same second and status is fooled into thinking foo
is clean.
A configuration item is used to determine the timeout, since different
filesystems may have different requirements (I think VFAT needs 3s,
while most Unix filesystems are fine with 1s).
- Example: "hg tag -r 42 build-25 beta-1" will add tags build-25 and beta-1
for rev 42.
- The deprecated and undocumented usage "hg tag arg1 arg2" used to emit a
warning, then add tag arg1 for rev arg2 (equivalent to "hg tag -r arg2 arg1").
It will now add tags arg1 and arg2 for the current revision.
- If one tag triggers an error, no tags are added/removed (all or nothing).
If we don't change any rwx bit in the last test, hg will skip the
calls to chmod since it'll assume they're not needed.
This might fix things on BSD systems.
This can make a difference when there are filters involved and
decode(encode(working-dir-data)) != working-dir-data
even though
encode(decode(repo-data)) == repo-data
An example is a working dir file that uses only \n when you're using
the win32text extension.
We encode the previous state as a negative file size (AFAICS, previous
versions of hg always have size == 0 when state == 'r').
We save the state of 'm'erged and dirty files, because they're the
two states that indicate that a file has to be committed on a merge
to correctly record per-file history.
The self patching of files when diffed with a backup is a bit peculiar to me.
It makes sense in mpatch, that's less clear in mercurial patching code. Let's
document and preserve it for now.
The only non-obvious part is the use of sys.{__stderr__,__stdout__},
which is needed because sshserver overrides sys.stdout.
This makes a test that I added back in revision d71c96fd819f ineffective.
The error message at startup when the address/port could not be bound
was confusing:
hg serve
abort: cannot start server: Address already in use
Be more explicit:
$ hg serve -a localhost
abort: cannot start server at 'localhost:8000': Address already in use
Also be more explicit on success, showing hostname and ip address/port:
$ hg -v serve -a localhost -p 80
listening at http://localhost/ (127.0.0.1:80)
We are careful to handle a missconfigured machine whose hostname does not
resolve, falling back to the address given at the command line.
Remove a dead-code error message.
This normalization consists of:
- stripping trailing whitespace
- always using "\n" as the line separator
I think the main reason rawcommit was skipping this normalization was
an attempt to preserve hashes during an hg->hg conversion.
While this is a nice goal, it's not particularly interesting in
practice. Since SHA-1 is so strong, the only safe way to do it is to
have absolutely identical revisions. But:
- if the original revision was created with a recent version of hg,
the commit message will be the same, with or without that
normalization
- if it was created with an ancient version of hg that didn't do any
normalization, even if the commit message is identical, the file list
in the changelog is likely to be different (e.g. no removed files),
and there were some old issues with e.g. extra file merging, which
will end up changing the hash anyway
- in any case, if one *really* has to preserve hashes, it's easier
(and faster) to fake a partial conversion using something like:
hg clone -U -r rev orig-repo new-repo
hg -R new-repo log --template '#node# #node#\n' > new-repo/.hg/shamap
Additionally, we've had some reports of problems arising from this lack
of normalization - e.g. issue871, and a user that was wondering why
hg export/hg import was not preserving hashes when there was nothing
unusual going on (it was just import doing the normalization that had
been skipped).
This also means that it's even more unlikely to get identical revisions
when going $VCS->hg->$VCS.
