Is there any way to back up and restore a filesystem that doesn't upset svnversion.
If I try the following set of operations:
- Check out a big SVN repository, and build the code
- Back up the SVN checkout folder
- Restore the SVN checkout to another location
Then the time to run svnversion on the backed up and restored copy is hugely more than on the original:
$ cd original_directory
$ echo 3 | sudo tee /proc/sys/vm/drop_caches
$ time svnversion
real 0m5.204s
user 0m0.486s
sys 0m0.698s
$ cd backed_up_and_restored_directory
$ echo 3 | sudo tee /proc/sys/vm/drop_caches
$ time svnversion
real 1m55.846s
user 0m2.813s
sys 0m5.653s
The echo 3 | sudo tee /proc/sys/vm/drop_caches is to clear the Linux cache so I am measuring "from cold". A second svnversion in either folder takes a fraction of a second.
I am seeing the same sort of result for all the backup technologies I have tried so far (tar, rsync, and ext4 dump/restore). I am also seeing similar behaviour across a variety of file systems (ext4, btrfs, gluster), and Linux distributions (Debian 8, Debian 9 and Ubuntu 16.04)
In answer to Gerard's question, a couple of example backup/restore commands:
rsync:
rsync -x -aH --whole-file --delete source_directory/ destination_directory
dump/restore:
dump 0uaf backup_file.dump .
restore -rf backup_file.dump
I assume this is happening because the restored files and subdirectories are being stored on the disk in a different order, which is making svnversion run very inefficiently on the copy.
Has anyone else experienced this, and does anyone know of a Linux backup/restore technique that will keep the files and directories "in the same order" to prevent this issue?
