implemented upgrade of direct mode repo to v6
This commit is contained in:
parent
cdd27b8920
commit
f9d077186a
4 changed files with 101 additions and 15 deletions
|
@ -323,8 +323,12 @@ files to be unlocked, while the indirect upgrades don't touch the files.
|
|||
|
||||
* Dropping a smudged file causes git status to show it as modified,
|
||||
because the timestamp has changed. Getting a smudged file can also
|
||||
cause this. Avoid this by preserving timestamp of smudged files
|
||||
when manipulating.
|
||||
cause this. Upgrading a direct mode repo also leaves files in this state.
|
||||
User can use `git add` to clear it up, but better to avoid this,
|
||||
by updating stat info in the index.
|
||||
(May need to use libgit2 to do this, cannot find
|
||||
any plumbing except git-update-index, which is very inneficient for
|
||||
smudged files.)
|
||||
* Reconcile staged changes into the associated files database, whenever
|
||||
the database is queried.
|
||||
* See if the cases where the Keys database is not used can be
|
||||
|
@ -335,8 +339,6 @@ files to be unlocked, while the indirect upgrades don't touch the files.
|
|||
(when not in direct mode).
|
||||
However, beware over-optimisation breaking the assistant or perhaps other
|
||||
long-lived processes.
|
||||
* Make v6 upgrade convert direct mode repo to repo with all unlocked
|
||||
files.
|
||||
* Make automatic merge conflict resolution work for pointer files.
|
||||
- Should probably automatically handle merge conflicts between annex
|
||||
symlinks and pointer files too. Maybe by always resulting in a pointer
|
||||
|
|
|
@ -48,6 +48,12 @@ The upgrade events, so far:
|
|||
The upgrade from v5 to v6 is handled manually. Run `git-annex upgrade`
|
||||
perform the upgrade.
|
||||
|
||||
Warning: All places that a direct mode repository is cloned to should be
|
||||
running git-annex version 6.x before you upgrade the repository.
|
||||
This is necessary because the contents of the repository are changed
|
||||
in the upgrade, and the old version of git-annex won't be able to
|
||||
access files after the repo is upgraded.
|
||||
|
||||
This upgrade does away with the direct mode/indirect mode distinction.
|
||||
A v6 git-annex repository can have some files locked and other files
|
||||
unlocked, and all git and git-annex commands can be used on both locked and
|
||||
|
@ -65,19 +71,13 @@ 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.
|
||||
|
||||
All places that a direct mode repository is cloned to should be
|
||||
running git-annex version 6.x before you upgrade the repository.
|
||||
This is necessary because the contents of the repository are changed
|
||||
in the upgrade, and the old version of git-annex won't be able to
|
||||
access files after the repo is upgraded.
|
||||
|
||||
If a repository is only used in indirect mode, you can use git-annex
|
||||
v5 and v6 in different clones of the same indirect mode repository without
|
||||
problems.
|
||||
|
||||
On upgrade, all files in a direct mode repository will be converted to
|
||||
unlocked files. The upgrade will need to stage changes to all files in
|
||||
the git repository.
|
||||
unlocked files. The upgrade will stage changes to all annexed files in
|
||||
the git repository, which you can then commit.
|
||||
|
||||
If a repository has some clones using direct mode and some using indirect
|
||||
mode, all the files will end up unlocked in all clones after the upgrade.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue