mention synchronized upgrades limitation
This commit is contained in:
parent
14e6d7cf2d
commit
b4329466c3
1 changed files with 8 additions and 0 deletions
|
@ -44,6 +44,10 @@ The upgrade process needs to write to the repository. If the original
|
|||
repository cannot be written to (due to eg being on readonly media),
|
||||
the upgrade would need to be run in a copy of the repository.
|
||||
|
||||
Some upgrades (most notably v6 and v7) require that all users of the
|
||||
repository upgrade simultaneously, otherwise files may become unreadable
|
||||
or unfetchable.
|
||||
|
||||
The upgrade events, so far:
|
||||
|
||||
## v6 -> v7 (git-annex version 7.x)
|
||||
|
@ -79,6 +83,10 @@ The behavior of some commands changes in an upgraded repository:
|
|||
* `git annex unlock` and `git annex lock` change how the pointer to
|
||||
the annexed content is stored in git.
|
||||
|
||||
If you commit the unlocked files change, this will impact all clones of the
|
||||
repository. This means all clones of the repository will need to run at least
|
||||
v6 to correctly synchronise.
|
||||
|
||||
There is also a new `annex.thin` setting, which makes unlocked files in v6
|
||||
repositories be hard linked to their content, instead of a copy. This saves
|
||||
disk space but means any modification of an unlocked file will lose the
|
||||
|
|
Loading…
Reference in a new issue