close todo and open new one

doc/todo/Metadata_changes_are_not_reflected_in_a_view.mdwn

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

doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_6_9d3d9877e8581f986257dd3d495a8eab._comment

@@ -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.
+"""]]

doc/todo/faster_incremental_update_of_view_branch_by_git-annex_sync.mdwn

@@ -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.
+