mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

update for v6 unlocked files

Browse source
This commit is contained in:
Joey Hess 2015-12-26 14:59:06 -04:00
parent 60c36ef6ba
commit 0fe43d7f8e
Failed to extract signature
1 changed files with 7 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
doc/design/metadata.mdwn
View file

@ -103,9 +103,8 @@ want to see.
* Could use filename metadata for the key, recorded by git-annex add (which * Could use filename metadata for the key, recorded by git-annex add (which
may not correspond to filenames being used in regular git branches like may not correspond to filenames being used in regular git branches like
master for the key). master for the key).
* Could use the .map files to get a filename, but this is somewhat * Could use the Keys database's associated files. Currently only works for v6
arbitrary (.map can contain multiple filenames), and is only unlocked files, and not for locked files.
currently supported in direct mode.
* Current approach: Have a reference branch (eg master) and walk it to * Current approach: Have a reference branch (eg master) and walk it to
find filenames and find filenames and
keys. Fine as long as it can be done efficiently. Also allows including keys. Fine as long as it can be done efficiently. Also allows including
@ -144,26 +143,13 @@ in the git-annex branch. This is slow. A fast cache is needed.
TODO TODO
# direct mode issues # unlocked file issues
TODO (direct mode is currently not supported with view branches) View branches can't be used in direct mode repositories.
Checking out a view branch can result in any number of copies of a file But, view branches do work with unlocked files in v6 repositories.
appearing in different directories. No problem in indirect mode, but The resulting view branch has all its files locked, although you
in direct mode these are real, expensive copies. can unlock them again after entering the branch.
But, it's worth supporting direct mode!
So, possible approaches:
* Before checking out a view branch, calculate how much space will
be used by duplicates and refuse if not enough is free.
* Only check out one file, and omit the copies. Keep track of which
files were omitted, and make sure that when committing on the branch,
that metadata is not removed. Has the downside that files can seem
to randomly move around in the tree as their metadata changes.
* Disallow view branch checkouts that have duplicate files.
This would cripple it some, but perhaps not too badly?
# gotchas # gotchas