view tests/test-merge5.t @ 17659:ae57920ac188 stable

largefiles: enable islfilesrepo() prior to a commit (issue3541)

Previously, even if a file was added with --large, 'hg addremove' or 'hg ci -A'
would add all files (including the previously added large files) as normal
files.  Only after a commit where a file was added with --large would subsequent
adds or 'ci -A' take into account the minsize or the pattern configuration.
This change more closely follows the help for largefiles, which mentions that
'add --large' is required to enable the configuration, but doesn't mention the
previously required commit.

Also, if 'hg add --large' was performed and then 'hg forget <file>' (both before
a largefile enabling commit), the forget command would error out saying
'.hglf/<file> not tracked'.  This is also fixed.

This reports that a repo is largefiles enabled as soon as a file is added with
--large, which enables 'add', 'addremove' and 'ci -A' to honor the config
settings before the first commit.  Note that prior to the next commit, if all
largefiles are forgotten, the repository goes back to reporting the repo as not
largefiles enabled.

It makes no sense to handle this by adding a --large option to 'addremove',
because then it would also be needed for 'commit', but only when '-A' is
specified.  While this gets around the awkwardness of having to add a largefile,
then commit it, and then addremove the other files when importing an existing
codebase (and preserving that extra commit in permanent history), it does still
require finding and manually adding one of the files as --large.  Therefore it
is probably desirable to have a --large option for init as well.

  $ hg init
  $ echo This is file a1 > a
  $ echo This is file b1 > b
  $ hg add a b
  $ hg commit -m "commit #0"
  $ echo This is file b22 > b
  $ hg commit -m "comment #1"
  $ hg update 0
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ rm b
  $ hg commit -A -m "comment #2"
  removing b
  created new head
  $ hg update 1
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ hg update
  abort: crosses branches (merge branches or update --check to force update)
  [255]
  $ hg update -c
  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
  $ mv a c

In theory, we shouldn't need the "-y" below, but it prevents this test
from hanging when "hg update" erroneously prompts the user for "keep
or delete".

Should abort:

  $ hg update -y 1
  abort: crosses branches (merge branches or use --clean to discard changes)
  [255]
  $ mv c a

Should succeed:

  $ hg update -y 1
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved