On Windows, we store symlinks as plain files with the link contents.
Via user error or NFS/Samba assistance, these files often end up with
'normal' file contents. Committing these changes thus gives an
invalid symlink that can't be checked out on Unix.
Here we filter out any modified symlink placeholders that look
suspicious when computing status:
- more than 1K (looks more like a normal file)
- contain NULs (not allowed on Unix, probably a binary)
- contains \n (filenames can't contain \n, very unusual for symlinks,
very common for files)
This gets us very close to full test coverage of lfconvert. The only
features not tested are:
- .hgtags conversion
- abort when largefile becomes symlink
- instead of converting a single changeset with a single file, convert
two changesets which each add a mix of normal and large files
- make one of the large files not-so-large, but identified as large
by filename
- use shorter, simpler filenames
- put some files in a subdirectory
- test that file contents are correctly converted
- drop unnecessary cleanup step
test-largefiles.t is getting pretty big, and there's lots more to test
in lfconvert. And lfconvert is a fairly orthogonal feature to the
rest of largefiles.
Before this patch, Windows always did the wrong thing with exec bits
when committing a merge: consult the flags in first parent.
Now we manually recompute the result of merging flags at commit time,
which almost always does the right thing (except when there are
conflicts between symlink and exec flags).
To do this, we:
- pull flag synthesis out into its own function
- delay building this function unless it's needed
- add a merge case that compares flags in local and other against the ancestor
This has been tested in multiple ways on Linux:
- running the whole test suite with both old and new code in place,
checking for differences in each flags() result
- running the whole test suite while comparing real on-disk flags
against synthetic ones for merges
- test-issue1802 (from Martin Geisler) which disables exec bit
checking on Unix
This reintroduces tests for the case described by issue3066, among others:
- vanilla clients and servers should still be able to talk to largefiles
clients and servers about vanilla repos
- vanilla clients should not attempt to clone largefiles repos over http and
should report a useful error message (issue3066; this appears to work
correctly)
- vanilla clients should not attempt to clone largefiles repos over ssh, again
with a useful error message
- largefiles clients should not attempt to push largefile changes to vanilla
servers
This is consistent with the rest of Mercurial's code, mirroring the
try-finally-unlink structure elsewhere. Furthermore, it fixes the case where
largefiles throws an IOError on Windows when the temporary file is opened a
second time by copytocacheabsolute.
This patch creates the temporary file in the repo's largefiles store rather than
/tmp, which might be a different filesystem.
When renaming a patch A as B where B was previously qfolded into A and
therefore marked as removed, a versioned MQ would first restore B before
marking it as a copy of A, thus losing A changes. The undelete() call is
probably a left-over, wctx.copy() explicitely handles the case where the
destination is removed.
Also note that status command represents "hg rm b; hg mv a b" as:
A b
a
R a
which explains the first hunk in test-mq-qrename.t.
This changeset flips the default value of ui.commitsubrepos setting
from True to False and adds a --subrepos flag to commit.
The commit, status, and diff commands behave like this with regard to
recusion and the ui.commitsubrepos setting:
| recurses | recurses
| by default | with --subrepos
--------+---------------+----------------
commit: | commitsubrepo | True
status: | False | True
diff: | False | True
By changing the default from True to False, the table becomes
consistent in the two columns:
* without --subrepos on the command line, commit will abort if a
subrepo is dirty and status/diff wont show changes inside subrepos.
* with --subrepos, all three commands will recurse.
A --subrepos flag on the command line overrides the config settin.g
The original intent was that the largefiles would primarily be in the
repository, with the global cache being only that--a cache. The naming
conventions and actual intent have both strayed. In this first patch, the
naming conventions are switched to match the actual intent, as are the
configuration options.
