how to implement this?

This commit is contained in:
Joey Hess 2022-04-05 14:52:09 -04:00
parent b1ba03216a
commit 469801c886
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 28 additions and 3 deletions

View file

@ -22,6 +22,4 @@ tree as well, but now it's getting complicated indeed.
> scrubbed from the branch. In any case a key is probably referred to in
> the master branch too.
>
> It's still useful to implement this, just to reduce branch size.
[[!tag confirmed]]
> It'd still be useful to implement this, just to reduce branch size.

View file

@ -0,0 +1,27 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2022-04-05T18:39:44Z"
content="""
Took a look at implementing this, and found a challenging problem.
A TransitionCalculator for this would need a way to check if a given key is
dead. Which means that the TransitionCalculator would need to run in Annex,
and read the location log for the key in order to decide whether to keep
a log file associated with that key.
That would make this transition be a lot slower to calculate than
transitions are now -- currently transitions only need the content of the
file they are acting on, and information that can be looked up before
starting like the TrustMap. This new transition would be doing a lot of
git-annex branch queries.
The other problem is that, if a key is dead, the location log for it ought
to be removed by the transition. But then calculating transitions for other
log files associated with that key would not be able to read the location
log to know it's dead.
Just caching in memory what dead keys have had their location logs removed
would not necessarily be enough either -- if a clone added information to a
log file associated with a dead key, then on merge from that clone, if
the transition is re-run it would no longer know that the key was dead.
"""]]