close todo and open new one

This commit is contained in:
Joey Hess 2023-02-10 15:51:38 -04:00
parent e9b6efac5a
commit 551d5abeb5
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 34 additions and 0 deletions

View file

@ -29,3 +29,5 @@ git-annex version: 5.20141024~bpo70+1
on debian wheezy with backports on debian wheezy with backports
### Please provide any additional information below. ### Please provide any additional information below.
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="joey"
subject="""comment 6"""
date="2023-02-10T19:49:51Z"
content="""
I've now fixed `git-annex sync`'s other behavior when ran in a view branch
to be acceptable.
I'm going to close this as fixed. But have opened
[[faster_incremental_update_of_view_branch_by_git-annex_sync]] as the
performance could be improved.
"""]]

View file

@ -0,0 +1,20 @@
git-annex sync, when run in a view branch, regenerates the view branch from
scratch. That is as expensive as entering the view branch in the first
place, which can take quite a long time when there are a lot of files.
And users with a lot of files are just the kind of user a view branch
appeals to..
There is probably a lot of scope for optimisation in updating the view
branch, that might be able to get it reasonably quick.
I have not fully thought through it, but basically diffing from the old
parent branch to the new parent to find files that have changed, and
adding/removing those from the view. And also diffing from the old
git-annex branch tree to the new one to get changes to metadata logs,
parsing those and using changes to metadata to also move/delete/add
files to the view branch.
It may also be that just improving the precaching of metadata logs
would improve the speed a lot. The streaming precaching of location logs
sped up some commands around 2x before IIRC.