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

Merge branch 'master' into sqlite

Browse source
This commit is contained in:
Joey Hess 2019-11-05 12:59:28 -04:00
commit 6147130e86
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
26 changed files with 355 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

1
doc/todo/git-annex-sync_handling_of_linked_worktrees.mdwn Normal file
View file

@ -0,0 +1 @@
When using [[linked worktrees|tips/Using_git-worktree_with_annex]], the main tree is currently handled differently from the linked trees: "if there is change in the tree then syncing doesn't update git worktrees and their indices, but updates the checked out branches. This is different to the handling of the main working directory as it's either got updated or left behind with its branch if there is a conflict." Is there a reason for this? Could linked worktrees be treated same as main one?

8
doc/todo/lockdown_hooks/comment_3_f57299385578914f5bca05f06b76cd46._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="ACLs keep fighting back"
date="2019-10-29T18:03:57Z"
content="""
I am getting back to tackle a datalad/git-annex usecase on one of such (nfs4 ACL) usecases, so if hooks are still the way to go, I will be ready to test ;-)
"""]]

21
doc/todo/sqlite_database_improvements.mdwn
View file

@ -2,6 +2,9 @@ Collection of non-ideal things about git-annex's use of sqlite databases.
Would be good to improve these sometime, but it would need a migration
process.
The `sqlite` branch changes the databases, updating annex.version to 8.
This todo documents the state of that branch.
* Database.Keys.SQL.isInodeKnown has some really ugly SQL LIKE queries.
Probably an index would not speed them up. They're only needed when
git-annex detects inodes are not stable, eg on fat or probably windows.
@ -107,16 +110,10 @@ remaining todo:
> situations, the next time an export is run, so should be ok.
> But it might result in already exported files being re-uploaded,
> or other unncessary work.
> Keys (IKey, SFilePath)
> rebuild with scanUnlockedFiles
> Keys (IKey, SFilePath, SInodeCache)
> Use scanUnlockedFiles to repopulate the Associated table.
>
> does that update the Content table with the InodeCache?
>
> But after such a transition, how to communicate to the old git-annex
> that it can't use the databases any longer? Moving the databases
> out of the way won't do; old git-annex will just recreate them and
> start with missing data!
>
> And, what about users who use a mix of old and new git-annex versions?
>
> Seems this needs an annex.version bump from v7 to v8.
> But that does not repopulate the Content table. Doing so needs
to iterate over the unlocked files, filter out any that are modified,
and record the InodeCaches of the unmodified ones. Seems that it would
have to use git's index to know which files are modified.

6
doc/todo/warn_of_breaking_changes_same_way_git_does.mdwn
View file

@ -1 +1,7 @@
When git introduces a breaking change, it prints a warning describing the change and saying "to turn off this warning set advice.warnaboutthis=false". This adds the hassle of setting the config (once, globally), but the reduced confusion might be worth it.
git also uses this mechanism to start warning of upcoming breaking changes in future versions, before these versions become current.
Another way to signal breaking changes can be to use some form of [semantic versioning](https://semver.org/) for git-annex versions, bumping the major version number to indicate incompatible changes. [[7.20190912|news/version_7.20190912]] would then be 8.20190912 . This would help when specifying [package dependencies](https://docs.conda.io/projects/conda-build/en/latest/resources/package-spec.html#package-match-specifications).
Of course, best is to avoid breaking changes, as @joeyh ultimately [[managed to do with v7|news/version_7.20191024]]. But they'll happen, and some people miss the [[current scheme for announcing them|forum/lets_discuss_git_add_behavior/#comment-727918fd9abda5445891f2022ac225c8]], so low-cost ways to extend the scheme might help.