2012-10-14 22:44:08 +04:00
|
|
|
$ USERCACHE="$TESTTMP/cache"; export USERCACHE
|
|
|
|
$ mkdir "${USERCACHE}"
|
2011-10-22 21:48:56 +04:00
|
|
|
$ cat >> $HGRCPATH <<EOF
|
2015-10-16 04:54:52 +03:00
|
|
|
> [format]
|
|
|
|
> usegeneraldelta=yes
|
2011-10-22 21:48:56 +04:00
|
|
|
> [extensions]
|
|
|
|
> largefiles =
|
2011-10-22 22:17:19 +04:00
|
|
|
> share =
|
2013-11-22 20:10:08 +04:00
|
|
|
> strip =
|
2012-10-24 05:07:14 +04:00
|
|
|
> convert =
|
2011-10-22 21:48:56 +04:00
|
|
|
> [largefiles]
|
|
|
|
> minsize = 0.5
|
2011-11-24 12:54:50 +04:00
|
|
|
> patterns = **.other
|
|
|
|
> **.dat
|
2012-10-14 22:44:08 +04:00
|
|
|
> usercache=${USERCACHE}
|
2011-10-22 21:48:56 +04:00
|
|
|
> EOF
|
|
|
|
|
|
|
|
"lfconvert" works
|
|
|
|
$ hg init bigfile-repo
|
|
|
|
$ cd bigfile-repo
|
2011-10-22 22:52:05 +04:00
|
|
|
$ cat >> .hg/hgrc <<EOF
|
|
|
|
> [extensions]
|
|
|
|
> largefiles = !
|
|
|
|
> EOF
|
|
|
|
$ mkdir sub
|
|
|
|
$ dd if=/dev/zero bs=1k count=256 > large 2> /dev/null
|
2012-01-08 20:09:01 +04:00
|
|
|
$ dd if=/dev/zero bs=1k count=256 > large2 2> /dev/null
|
2011-10-22 22:52:05 +04:00
|
|
|
$ echo normal > normal1
|
|
|
|
$ echo alsonormal > sub/normal2
|
|
|
|
$ dd if=/dev/zero bs=1k count=10 > sub/maybelarge.dat 2> /dev/null
|
2011-10-22 21:48:56 +04:00
|
|
|
$ hg addremove
|
2011-10-22 22:52:05 +04:00
|
|
|
adding large
|
2012-01-08 20:09:01 +04:00
|
|
|
adding large2
|
2011-10-22 22:52:05 +04:00
|
|
|
adding normal1
|
|
|
|
adding sub/maybelarge.dat
|
|
|
|
adding sub/normal2
|
|
|
|
$ hg commit -m"add large, normal1" large normal1
|
|
|
|
$ hg commit -m"add sub/*" sub
|
2012-06-10 20:50:42 +04:00
|
|
|
|
2012-01-08 20:09:01 +04:00
|
|
|
Test tag parsing
|
|
|
|
$ cat >> .hgtags <<EOF
|
|
|
|
> IncorrectlyFormattedTag!
|
|
|
|
> invalidhash sometag
|
|
|
|
> 0123456789abcdef anothertag
|
|
|
|
> EOF
|
|
|
|
$ hg add .hgtags
|
|
|
|
$ hg commit -m"add large2" large2 .hgtags
|
2012-06-10 20:50:42 +04:00
|
|
|
|
2012-01-08 20:09:01 +04:00
|
|
|
Test link+rename largefile codepath
|
2011-10-22 22:52:05 +04:00
|
|
|
$ [ -d .hg/largefiles ] && echo fail || echo pass
|
|
|
|
pass
|
2011-10-22 21:48:56 +04:00
|
|
|
$ cd ..
|
|
|
|
$ hg lfconvert --size 0.2 bigfile-repo largefiles-repo
|
|
|
|
initializing destination largefiles-repo
|
2012-01-08 20:09:01 +04:00
|
|
|
skipping incorrectly formatted tag IncorrectlyFormattedTag!
|
|
|
|
skipping incorrectly formatted id invalidhash
|
|
|
|
no mapping for id 0123456789abcdef
|
2012-06-10 20:50:42 +04:00
|
|
|
#if symlink
|
|
|
|
$ hg --cwd bigfile-repo rename large2 large3
|
|
|
|
$ ln -sf large bigfile-repo/large3
|
|
|
|
$ hg --cwd bigfile-repo commit -m"make large2 a symlink" large2 large3
|
|
|
|
$ hg lfconvert --size 0.2 bigfile-repo largefiles-repo-symlink
|
|
|
|
initializing destination largefiles-repo-symlink
|
|
|
|
skipping incorrectly formatted tag IncorrectlyFormattedTag!
|
|
|
|
skipping incorrectly formatted id invalidhash
|
|
|
|
no mapping for id 0123456789abcdef
|
2012-01-08 20:09:01 +04:00
|
|
|
abort: renamed/copied largefile large3 becomes symlink
|
|
|
|
[255]
|
2012-06-10 20:50:42 +04:00
|
|
|
#endif
|
2012-01-08 20:09:01 +04:00
|
|
|
$ cd bigfile-repo
|
|
|
|
$ hg strip --no-backup 2
|
|
|
|
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
|
|
|
|
$ cd ..
|
2012-06-10 20:50:42 +04:00
|
|
|
$ rm -rf largefiles-repo largefiles-repo-symlink
|
|
|
|
|
2012-01-08 20:09:01 +04:00
|
|
|
$ hg lfconvert --size 0.2 bigfile-repo largefiles-repo
|
|
|
|
initializing destination largefiles-repo
|
2011-10-22 21:48:56 +04:00
|
|
|
|
2011-10-22 22:52:05 +04:00
|
|
|
"lfconvert" converts content correctly
|
|
|
|
$ cd largefiles-repo
|
|
|
|
$ hg up
|
|
|
|
getting changed largefiles
|
|
|
|
2 largefiles updated, 0 removed
|
2013-01-23 03:51:53 +04:00
|
|
|
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
2011-10-22 22:52:05 +04:00
|
|
|
$ hg locate
|
|
|
|
.hglf/large
|
|
|
|
.hglf/sub/maybelarge.dat
|
|
|
|
normal1
|
|
|
|
sub/normal2
|
|
|
|
$ cat normal1
|
|
|
|
normal
|
|
|
|
$ cat sub/normal2
|
|
|
|
alsonormal
|
2015-06-08 22:44:30 +03:00
|
|
|
$ md5sum.py large sub/maybelarge.dat
|
2011-10-31 23:22:11 +04:00
|
|
|
ec87a838931d4d5d2e94a04644788a55 large
|
|
|
|
1276481102f218c981e0324180bafd9f sub/maybelarge.dat
|
2011-10-22 22:52:05 +04:00
|
|
|
|
2011-10-22 21:48:56 +04:00
|
|
|
"lfconvert" adds 'largefiles' to .hg/requires.
|
2011-10-22 22:52:05 +04:00
|
|
|
$ cat .hg/requires
|
2012-12-12 05:38:14 +04:00
|
|
|
dotencode
|
|
|
|
fncache
|
2015-10-16 04:54:52 +03:00
|
|
|
generaldelta
|
2011-10-22 21:48:56 +04:00
|
|
|
largefiles
|
|
|
|
revlogv1
|
|
|
|
store
|
|
|
|
|
|
|
|
"lfconvert" includes a newline at the end of the standin files.
|
2011-10-22 22:52:05 +04:00
|
|
|
$ cat .hglf/large .hglf/sub/maybelarge.dat
|
2011-10-22 21:48:56 +04:00
|
|
|
2e000fa7e85759c7f4c254d4d9c33ef481e459a7
|
2011-10-22 22:52:05 +04:00
|
|
|
34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
|
2011-10-22 22:17:19 +04:00
|
|
|
$ cd ..
|
|
|
|
|
2011-10-22 23:16:52 +04:00
|
|
|
add some changesets to rename/remove/merge
|
|
|
|
$ cd bigfile-repo
|
|
|
|
$ hg mv -q sub stuff
|
|
|
|
$ hg commit -m"rename sub/ to stuff/"
|
|
|
|
$ hg update -q 1
|
|
|
|
$ echo blah >> normal3
|
|
|
|
$ echo blah >> sub/normal2
|
|
|
|
$ echo blah >> sub/maybelarge.dat
|
2015-06-08 22:44:30 +03:00
|
|
|
$ md5sum.py sub/maybelarge.dat
|
2011-10-31 23:22:11 +04:00
|
|
|
1dd0b99ff80e19cff409702a1d3f5e15 sub/maybelarge.dat
|
2011-10-22 23:16:52 +04:00
|
|
|
$ hg commit -A -m"add normal3, modify sub/*"
|
|
|
|
adding normal3
|
|
|
|
created new head
|
|
|
|
$ hg rm large normal3
|
|
|
|
$ hg commit -q -m"remove large, normal3"
|
|
|
|
$ hg merge
|
|
|
|
merging sub/maybelarge.dat and stuff/maybelarge.dat to stuff/maybelarge.dat
|
2015-10-12 07:56:39 +03:00
|
|
|
merging sub/normal2 and stuff/normal2 to stuff/normal2
|
2017-09-16 05:08:25 +03:00
|
|
|
warning: stuff/maybelarge.dat looks like a binary file.
|
2015-10-09 23:54:52 +03:00
|
|
|
warning: conflicts while merging stuff/maybelarge.dat! (edit, then use 'hg resolve --mark')
|
2011-10-22 23:16:52 +04:00
|
|
|
0 files updated, 1 files merged, 0 files removed, 1 files unresolved
|
|
|
|
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
|
|
|
|
[1]
|
|
|
|
$ hg cat -r . sub/maybelarge.dat > stuff/maybelarge.dat
|
|
|
|
$ hg resolve -m stuff/maybelarge.dat
|
2014-07-26 05:32:49 +04:00
|
|
|
(no more unresolved files)
|
2011-10-22 23:16:52 +04:00
|
|
|
$ hg commit -m"merge"
|
2013-11-22 22:14:17 +04:00
|
|
|
$ hg log -G --template "{rev}:{node|short} {desc|firstline}\n"
|
2011-10-22 23:16:52 +04:00
|
|
|
@ 5:4884f215abda merge
|
|
|
|
|\
|
|
|
|
| o 4:7285f817b77e remove large, normal3
|
|
|
|
| |
|
|
|
|
| o 3:67e3892e3534 add normal3, modify sub/*
|
|
|
|
| |
|
|
|
|
o | 2:c96c8beb5d56 rename sub/ to stuff/
|
|
|
|
|/
|
|
|
|
o 1:020c65d24e11 add sub/*
|
|
|
|
|
|
|
|
|
o 0:117b8328f97a add large, normal1
|
|
|
|
|
|
|
|
$ cd ..
|
|
|
|
|
|
|
|
lfconvert with rename, merge, and remove
|
2011-10-22 23:39:51 +04:00
|
|
|
$ rm -rf largefiles-repo
|
|
|
|
$ hg lfconvert --size 0.2 bigfile-repo largefiles-repo
|
|
|
|
initializing destination largefiles-repo
|
|
|
|
$ cd largefiles-repo
|
2013-11-22 22:14:17 +04:00
|
|
|
$ hg log -G --template "{rev}:{node|short} {desc|firstline}\n"
|
2011-10-22 23:16:52 +04:00
|
|
|
o 5:8e05f5f2b77e merge
|
|
|
|
|\
|
|
|
|
| o 4:a5a02de7a8e4 remove large, normal3
|
|
|
|
| |
|
|
|
|
| o 3:55759520c76f add normal3, modify sub/*
|
|
|
|
| |
|
|
|
|
o | 2:261ad3f3f037 rename sub/ to stuff/
|
|
|
|
|/
|
|
|
|
o 1:334e5237836d add sub/*
|
|
|
|
|
|
|
|
|
o 0:d4892ec57ce2 add large, normal1
|
|
|
|
|
|
|
|
$ hg locate -r 2
|
|
|
|
.hglf/large
|
|
|
|
.hglf/stuff/maybelarge.dat
|
|
|
|
normal1
|
|
|
|
stuff/normal2
|
|
|
|
$ hg locate -r 3
|
|
|
|
.hglf/large
|
|
|
|
.hglf/sub/maybelarge.dat
|
|
|
|
normal1
|
|
|
|
normal3
|
|
|
|
sub/normal2
|
|
|
|
$ hg locate -r 4
|
|
|
|
.hglf/sub/maybelarge.dat
|
|
|
|
normal1
|
|
|
|
sub/normal2
|
|
|
|
$ hg locate -r 5
|
|
|
|
.hglf/stuff/maybelarge.dat
|
|
|
|
normal1
|
|
|
|
stuff/normal2
|
|
|
|
$ hg update
|
|
|
|
getting changed largefiles
|
|
|
|
1 largefiles updated, 0 removed
|
2013-01-23 03:51:53 +04:00
|
|
|
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
2011-10-22 23:16:52 +04:00
|
|
|
$ cat stuff/normal2
|
|
|
|
alsonormal
|
|
|
|
blah
|
2015-06-08 22:44:30 +03:00
|
|
|
$ md5sum.py stuff/maybelarge.dat
|
2011-10-31 23:22:11 +04:00
|
|
|
1dd0b99ff80e19cff409702a1d3f5e15 stuff/maybelarge.dat
|
2011-10-22 23:16:52 +04:00
|
|
|
$ cat .hglf/stuff/maybelarge.dat
|
|
|
|
76236b6a2c6102826c61af4297dd738fb3b1de38
|
|
|
|
$ cd ..
|
|
|
|
|
2011-10-22 22:17:19 +04:00
|
|
|
"lfconvert" error cases
|
2011-10-22 22:20:17 +04:00
|
|
|
$ hg lfconvert http://localhost/foo foo
|
|
|
|
abort: http://localhost/foo is not a local Mercurial repo
|
|
|
|
[255]
|
|
|
|
$ hg lfconvert foo ssh://localhost/foo
|
|
|
|
abort: ssh://localhost/foo is not a local Mercurial repo
|
|
|
|
[255]
|
2011-10-22 22:17:19 +04:00
|
|
|
$ hg lfconvert nosuchrepo foo
|
|
|
|
abort: repository nosuchrepo not found!
|
|
|
|
[255]
|
|
|
|
$ hg share -q -U bigfile-repo shared
|
2011-10-26 21:56:27 +04:00
|
|
|
$ printf 'bogus' > shared/.hg/sharedpath
|
2011-10-22 22:17:19 +04:00
|
|
|
$ hg lfconvert shared foo
|
2017-12-11 06:50:57 +03:00
|
|
|
abort: .hg/sharedpath points to nonexistent directory $TESTTMP/bogus!
|
2011-10-22 22:17:19 +04:00
|
|
|
[255]
|
|
|
|
$ hg lfconvert bigfile-repo largefiles-repo
|
|
|
|
initializing destination largefiles-repo
|
|
|
|
abort: repository largefiles-repo already exists!
|
|
|
|
[255]
|
2011-10-22 21:48:56 +04:00
|
|
|
|
2011-10-22 23:39:51 +04:00
|
|
|
add another largefile to the new largefiles repo
|
|
|
|
$ cd largefiles-repo
|
|
|
|
$ dd if=/dev/zero bs=1k count=1k > anotherlarge 2> /dev/null
|
|
|
|
$ hg add --lfsize=1 anotherlarge
|
|
|
|
$ hg commit -m "add anotherlarge (should be a largefile)"
|
|
|
|
$ cat .hglf/anotherlarge
|
|
|
|
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
$ hg tag mytag
|
2011-10-22 23:39:51 +04:00
|
|
|
$ cd ..
|
|
|
|
|
|
|
|
round-trip: converting back to a normal (non-largefiles) repo with
|
2017-11-29 07:20:08 +03:00
|
|
|
"lfconvert --to-normal" should give the same as ../bigfile-repo. The
|
|
|
|
convert extension is disabled to show config items can be loaded without it.
|
2011-10-22 22:17:19 +04:00
|
|
|
$ cd largefiles-repo
|
2017-11-29 07:20:08 +03:00
|
|
|
$ hg --config extensions.convert=! lfconvert --to-normal . ../normal-repo
|
2011-10-22 21:48:56 +04:00
|
|
|
initializing destination ../normal-repo
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
0 additional largefiles cached
|
|
|
|
scanning source...
|
|
|
|
sorting...
|
|
|
|
converting...
|
|
|
|
7 add large, normal1
|
|
|
|
6 add sub/*
|
|
|
|
5 rename sub/ to stuff/
|
|
|
|
4 add normal3, modify sub/*
|
|
|
|
3 remove large, normal3
|
|
|
|
2 merge
|
|
|
|
1 add anotherlarge (should be a largefile)
|
|
|
|
0 Added tag mytag for changeset abacddda7028
|
2011-10-22 21:48:56 +04:00
|
|
|
$ cd ../normal-repo
|
|
|
|
$ cat >> .hg/hgrc <<EOF
|
|
|
|
> [extensions]
|
|
|
|
> largefiles = !
|
|
|
|
> EOF
|
2011-10-22 23:39:51 +04:00
|
|
|
|
2013-11-22 22:14:17 +04:00
|
|
|
$ hg log -G --template "{rev}:{node|short} {desc|firstline}\n"
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
o 7:b5fedc110b9d Added tag mytag for changeset 867ab992ecf4
|
2011-10-22 23:39:51 +04:00
|
|
|
|
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
o 6:867ab992ecf4 add anotherlarge (should be a largefile)
|
|
|
|
|
|
|
|
|
o 5:4884f215abda merge
|
2011-10-22 23:39:51 +04:00
|
|
|
|\
|
|
|
|
| o 4:7285f817b77e remove large, normal3
|
|
|
|
| |
|
|
|
|
| o 3:67e3892e3534 add normal3, modify sub/*
|
|
|
|
| |
|
|
|
|
o | 2:c96c8beb5d56 rename sub/ to stuff/
|
|
|
|
|/
|
|
|
|
o 1:020c65d24e11 add sub/*
|
|
|
|
|
|
|
|
|
o 0:117b8328f97a add large, normal1
|
|
|
|
|
2011-10-22 21:48:56 +04:00
|
|
|
$ hg update
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
5 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
2011-10-22 21:48:56 +04:00
|
|
|
$ hg locate
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
.hgtags
|
2011-10-22 22:52:05 +04:00
|
|
|
anotherlarge
|
|
|
|
normal1
|
2011-10-22 23:39:51 +04:00
|
|
|
stuff/maybelarge.dat
|
|
|
|
stuff/normal2
|
2011-10-22 21:48:56 +04:00
|
|
|
$ [ -d .hg/largefiles ] && echo fail || echo pass
|
|
|
|
pass
|
2012-06-11 03:40:51 +04:00
|
|
|
|
|
|
|
$ cd ..
|
2012-10-14 22:44:08 +04:00
|
|
|
|
largefiles: don't copy largefiles from working dir to the store while converting
Previously, if one or more largefiles for a repo being converted were not in the
usercache, the convert would abort with a reference to the largefile being
missing (as opposed to the previous patch, where the standin was referenced as
missing). This is because commitctx() tries to copy all largefiles to the
local store, first from the user cache, and if the file isn't found there, from
the working directory. No files will exist in the working directory during a
convert, however. It is not sufficient to force the source repo to be local
before proceeding, because clone and pull do not download largefiles by default.
This is slightly less than ideal because while the conversion will now complete,
it won't be possible to update to revs with missing largefiles unless the user
intervenes manually, because there is no default path pointing back to the
source repo. Ideally these files would be cached during the conversion.
This check could have been done in reposetup.commitctx() instead, but this
ensures the local store directory is created, which is necessary to enable the
standin matcher.
The rm -> 'rm -f' change in the test is to temporarily suppress an error
clearing the cache- as noted, the cache is is not repopulated during convert.
When that is fixed, this can be changed back and the verification errors will
disappear too.
2012-10-24 05:32:19 +04:00
|
|
|
Clearing the usercache ensures that commitctx doesn't try to cache largefiles
|
|
|
|
from the working dir on a convert.
|
|
|
|
$ rm "${USERCACHE}"/*
|
2012-10-24 05:07:14 +04:00
|
|
|
$ hg convert largefiles-repo
|
|
|
|
assuming destination largefiles-repo-hg
|
|
|
|
initializing destination largefiles-repo-hg repository
|
|
|
|
scanning source...
|
|
|
|
sorting...
|
|
|
|
converting...
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
7 add large, normal1
|
|
|
|
6 add sub/*
|
|
|
|
5 rename sub/ to stuff/
|
|
|
|
4 add normal3, modify sub/*
|
|
|
|
3 remove large, normal3
|
|
|
|
2 merge
|
|
|
|
1 add anotherlarge (should be a largefile)
|
|
|
|
0 Added tag mytag for changeset abacddda7028
|
2012-10-24 05:07:14 +04:00
|
|
|
|
2013-11-22 22:14:17 +04:00
|
|
|
$ hg -R largefiles-repo-hg log -G --template "{rev}:{node|short} {desc|firstline}\n"
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
o 7:2f08f66459b7 Added tag mytag for changeset 17126745edfd
|
|
|
|
|
|
2012-10-24 05:07:14 +04:00
|
|
|
o 6:17126745edfd add anotherlarge (should be a largefile)
|
|
|
|
|
|
|
|
|
o 5:9cc5aa7204f0 merge
|
|
|
|
|\
|
|
|
|
| o 4:a5a02de7a8e4 remove large, normal3
|
|
|
|
| |
|
|
|
|
| o 3:55759520c76f add normal3, modify sub/*
|
|
|
|
| |
|
|
|
|
o | 2:261ad3f3f037 rename sub/ to stuff/
|
|
|
|
|/
|
|
|
|
o 1:334e5237836d add sub/*
|
|
|
|
|
|
|
|
|
o 0:d4892ec57ce2 add large, normal1
|
|
|
|
|
largefiles: don't copy largefiles from working dir to the store while converting
Previously, if one or more largefiles for a repo being converted were not in the
usercache, the convert would abort with a reference to the largefile being
missing (as opposed to the previous patch, where the standin was referenced as
missing). This is because commitctx() tries to copy all largefiles to the
local store, first from the user cache, and if the file isn't found there, from
the working directory. No files will exist in the working directory during a
convert, however. It is not sufficient to force the source repo to be local
before proceeding, because clone and pull do not download largefiles by default.
This is slightly less than ideal because while the conversion will now complete,
it won't be possible to update to revs with missing largefiles unless the user
intervenes manually, because there is no default path pointing back to the
source repo. Ideally these files would be cached during the conversion.
This check could have been done in reposetup.commitctx() instead, but this
ensures the local store directory is created, which is necessary to enable the
standin matcher.
The rm -> 'rm -f' change in the test is to temporarily suppress an error
clearing the cache- as noted, the cache is is not repopulated during convert.
When that is fixed, this can be changed back and the verification errors will
disappear too.
2012-10-24 05:32:19 +04:00
|
|
|
Verify will fail (for now) if the usercache is purged before converting, since
|
|
|
|
largefiles are not cached in the converted repo's local store by the conversion
|
|
|
|
process.
|
2015-06-07 05:10:18 +03:00
|
|
|
$ cd largefiles-repo-hg
|
|
|
|
$ cat >> .hg/hgrc <<EOF
|
|
|
|
> [experimental]
|
2017-09-28 20:19:06 +03:00
|
|
|
> evolution.createmarkers=True
|
2015-06-07 05:10:18 +03:00
|
|
|
> EOF
|
|
|
|
$ hg debugobsolete `hg log -r tip -T "{node}"`
|
2017-07-16 03:33:14 +03:00
|
|
|
obsoleted 1 changesets
|
2015-06-07 05:10:18 +03:00
|
|
|
$ cd ..
|
|
|
|
|
2012-10-24 05:07:14 +04:00
|
|
|
$ hg -R largefiles-repo-hg verify --large --lfa
|
|
|
|
checking changesets
|
|
|
|
checking manifests
|
|
|
|
crosschecking files in changesets and manifests
|
|
|
|
checking files
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
9 files, 8 changesets, 13 total revisions
|
2015-06-07 05:10:18 +03:00
|
|
|
searching 7 changesets for largefiles
|
2017-12-11 06:50:57 +03:00
|
|
|
changeset 0:d4892ec57ce2: large references missing $TESTTMP/largefiles-repo-hg/.hg/largefiles/2e000fa7e85759c7f4c254d4d9c33ef481e459a7
|
|
|
|
changeset 1:334e5237836d: sub/maybelarge.dat references missing $TESTTMP/largefiles-repo-hg/.hg/largefiles/34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
|
|
|
|
changeset 2:261ad3f3f037: stuff/maybelarge.dat references missing $TESTTMP/largefiles-repo-hg/.hg/largefiles/34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
|
|
|
|
changeset 3:55759520c76f: sub/maybelarge.dat references missing $TESTTMP/largefiles-repo-hg/.hg/largefiles/76236b6a2c6102826c61af4297dd738fb3b1de38
|
|
|
|
changeset 5:9cc5aa7204f0: stuff/maybelarge.dat references missing $TESTTMP/largefiles-repo-hg/.hg/largefiles/76236b6a2c6102826c61af4297dd738fb3b1de38
|
|
|
|
changeset 6:17126745edfd: anotherlarge references missing $TESTTMP/largefiles-repo-hg/.hg/largefiles/3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3
|
2012-10-24 05:07:14 +04:00
|
|
|
verified existence of 6 revisions of 4 largefiles
|
largefiles: don't copy largefiles from working dir to the store while converting
Previously, if one or more largefiles for a repo being converted were not in the
usercache, the convert would abort with a reference to the largefile being
missing (as opposed to the previous patch, where the standin was referenced as
missing). This is because commitctx() tries to copy all largefiles to the
local store, first from the user cache, and if the file isn't found there, from
the working directory. No files will exist in the working directory during a
convert, however. It is not sufficient to force the source repo to be local
before proceeding, because clone and pull do not download largefiles by default.
This is slightly less than ideal because while the conversion will now complete,
it won't be possible to update to revs with missing largefiles unless the user
intervenes manually, because there is no default path pointing back to the
source repo. Ideally these files would be cached during the conversion.
This check could have been done in reposetup.commitctx() instead, but this
ensures the local store directory is created, which is necessary to enable the
standin matcher.
The rm -> 'rm -f' change in the test is to temporarily suppress an error
clearing the cache- as noted, the cache is is not repopulated during convert.
When that is fixed, this can be changed back and the verification errors will
disappear too.
2012-10-24 05:32:19 +04:00
|
|
|
[1]
|
2012-10-24 05:07:14 +04:00
|
|
|
$ hg -R largefiles-repo-hg showconfig paths
|
2014-08-20 03:57:02 +04:00
|
|
|
[1]
|
2012-10-24 05:07:14 +04:00
|
|
|
|
|
|
|
|
2012-10-14 22:44:08 +04:00
|
|
|
Avoid a traceback if a largefile isn't available (issue3519)
|
|
|
|
|
2012-10-14 23:10:13 +04:00
|
|
|
Ensure the largefile can be cached in the source if necessary
|
2012-10-14 22:44:08 +04:00
|
|
|
$ hg clone -U largefiles-repo issue3519
|
largefiles: don't copy largefiles from working dir to the store while converting
Previously, if one or more largefiles for a repo being converted were not in the
usercache, the convert would abort with a reference to the largefile being
missing (as opposed to the previous patch, where the standin was referenced as
missing). This is because commitctx() tries to copy all largefiles to the
local store, first from the user cache, and if the file isn't found there, from
the working directory. No files will exist in the working directory during a
convert, however. It is not sufficient to force the source repo to be local
before proceeding, because clone and pull do not download largefiles by default.
This is slightly less than ideal because while the conversion will now complete,
it won't be possible to update to revs with missing largefiles unless the user
intervenes manually, because there is no default path pointing back to the
source repo. Ideally these files would be cached during the conversion.
This check could have been done in reposetup.commitctx() instead, but this
ensures the local store directory is created, which is necessary to enable the
standin matcher.
The rm -> 'rm -f' change in the test is to temporarily suppress an error
clearing the cache- as noted, the cache is is not repopulated during convert.
When that is fixed, this can be changed back and the verification errors will
disappear too.
2012-10-24 05:32:19 +04:00
|
|
|
$ rm -f "${USERCACHE}"/*
|
2012-10-14 22:44:08 +04:00
|
|
|
$ hg lfconvert --to-normal issue3519 normalized3519
|
|
|
|
initializing destination normalized3519
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
4 additional largefiles cached
|
|
|
|
scanning source...
|
|
|
|
sorting...
|
|
|
|
converting...
|
|
|
|
7 add large, normal1
|
|
|
|
6 add sub/*
|
|
|
|
5 rename sub/ to stuff/
|
|
|
|
4 add normal3, modify sub/*
|
|
|
|
3 remove large, normal3
|
|
|
|
2 merge
|
|
|
|
1 add anotherlarge (should be a largefile)
|
|
|
|
0 Added tag mytag for changeset abacddda7028
|
2012-10-14 23:10:13 +04:00
|
|
|
|
|
|
|
Ensure the abort message is useful if a largefile is entirely unavailable
|
|
|
|
$ rm -rf normalized3519
|
|
|
|
$ rm "${USERCACHE}"/*
|
|
|
|
$ rm issue3519/.hg/largefiles/*
|
|
|
|
$ rm largefiles-repo/.hg/largefiles/*
|
|
|
|
$ hg lfconvert --to-normal issue3519 normalized3519
|
|
|
|
initializing destination normalized3519
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
anotherlarge: largefile 3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3 not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
|
|
|
stuff/maybelarge.dat: largefile 76236b6a2c6102826c61af4297dd738fb3b1de38 not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
|
|
|
stuff/maybelarge.dat: largefile 76236b6a2c6102826c61af4297dd738fb3b1de38 not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
|
|
|
sub/maybelarge.dat: largefile 76236b6a2c6102826c61af4297dd738fb3b1de38 not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
|
|
|
large: largefile 2e000fa7e85759c7f4c254d4d9c33ef481e459a7 not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
|
|
|
sub/maybelarge.dat: largefile 76236b6a2c6102826c61af4297dd738fb3b1de38 not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
|
|
|
large: largefile 2e000fa7e85759c7f4c254d4d9c33ef481e459a7 not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
|
|
|
stuff/maybelarge.dat: largefile 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
|
|
|
large: largefile 2e000fa7e85759c7f4c254d4d9c33ef481e459a7 not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
|
|
|
sub/maybelarge.dat: largefile 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
2014-01-28 00:39:25 +04:00
|
|
|
large: largefile 2e000fa7e85759c7f4c254d4d9c33ef481e459a7 not available from file:/*/$TESTTMP/largefiles-repo (glob)
|
largefiles: use the convert extension for 'lfconvert --to-normal'
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
2015-05-28 20:34:37 +03:00
|
|
|
0 additional largefiles cached
|
|
|
|
11 largefiles failed to download
|
|
|
|
abort: all largefiles must be present locally
|
2012-10-14 22:44:08 +04:00
|
|
|
[255]
|
|
|
|
|
|
|
|
|