diff options
Diffstat (limited to 'doc/tips/Repositories_with_large_number_of_files.mdwn')
| -rw-r--r-- | doc/tips/Repositories_with_large_number_of_files.mdwn | 15 |
1 files changed, 11 insertions, 4 deletions
diff --git a/doc/tips/Repositories_with_large_number_of_files.mdwn b/doc/tips/Repositories_with_large_number_of_files.mdwn index c1f219eee..347f6f94a 100644 --- a/doc/tips/Repositories_with_large_number_of_files.mdwn +++ b/doc/tips/Repositories_with_large_number_of_files.mdwn @@ -1,5 +1,7 @@ Just as git does not scale well with large files, it can also become painful to work with when you have a large *number* of files. Below are things I have found to minimise the pain. +[[!toc]] + # Using version 4 index files During operations which affect the index, git writes an entirely new index out to index.lck and then replaces .git/index with it. With a large number of files, this index file can be quite large and take several seconds to write every time you manipulate the index! @@ -40,9 +42,14 @@ If it takes a long time to list the files in a directory, naturally, git(-annex) You can avoid this by keeping the number of files in a directory to between 5000 and 20000 (depends on the filesystem and its settings). -[fpart](http://contribs.martymac.org/fpart/) can be a very useful tool to achieve this. +[fpart](https://sourceforge.net/projects/fpart/) can be a very useful tool to achieve this. + +This sort of usage was discussed in [[forum/Handling_a_large_number_of_files]] and [[forum/__34__git_annex_sync__34___synced_after_8_hours]]. -- [[CandyAngel]] + +# Forget tracking information + +In addition to keeping track of where files are, git-annex keeps a *log* that keeps track of where files *were*. This can take up space as well and slow down certain operations. -## Topics discussing this sort of usage +You can use the [[git-annex-forget]] command to drop historical location tracking info for files. -* [[forum/Handling_a_large_number_of_files]] -* [[forum/__34__git_annex_sync__34___synced_after_8_hours]] +Note: this was discussed in [[forum/scalability_with_lots_of_files]]. -- [[anarcat]] |