Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
Joey Hess
commit
d4eaed5052
6 changed files with 51 additions and 28 deletions
|
|
@ -75,3 +75,5 @@ I also note that the `encryption step` part takes a looong time when we try to r
|
|||
Of course! As you very likely know, I use git-annex daily and I'm a really happy user. :) This is, however, the first time I give gcrypt a shot.
|
||||
|
||||
Thanks for your hard work! --[[anarcat]]
|
||||
|
||||
Update: turns out this is a bug in git-remote-gcrypt and this probably doesn't need to be tracked in git-annex. the workaround is to comment out the `push.sign=ifAsked` entry in the git config, or to make git-remote-gcrypt ignore unknown options. so [[done]]. --[[anarcat]]
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="anarcat"
|
||||
avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
|
||||
subject="comment 4"
|
||||
date="2018-05-22T20:54:13Z"
|
||||
content="""
|
||||
sent a crude patch by email.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
[[!comment format=mdwn
|
||||
username="andrew"
|
||||
avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
|
||||
subject="use case"
|
||||
date="2018-05-23T00:12:11Z"
|
||||
content="""
|
||||
Hmmm. Could you talk more about your use case “The use case I have in mind is syncing photos to an Android tablet in a v5 repository.”?
|
||||
|
||||
Lets say I have a nice collection of family photos on my desktop computer annexed in a folder called `family`. Lets say we have `numcopies` set at 1. I keep only the best photos, so it always takes up about 1gb. In the family folder I have nice organized sub-folders and I add new images occasionally. I have an Android tablet that sits on my coffee table and I want visitors to be able to open the tablet, run some gallery app and view all my family photos. Sometimes i'll grab the tablet and take it with me to family gatherings, so I want all the photos on in, ready for offline viewing.
|
||||
|
||||
With this use case, perhaps I run assistant inside termux. I clone family into `/data/data/com.termux/files/home` set it as standard group transfer and call it `t`, I also clone it into `/storage/emulated/0`, set it as standard group client, and call this crippled client repo `c`. Our `c` folder should now be accessible to any Android photo gallery app. As we make changes to `family`, on our desktop, assistant on the Android tablet brings them in, when we have wifi, it will probably copy them directly to `c`?
|
||||
|
||||
If I take a photo on my tablet, put it in the `c` directory (which is accessible from my photo app), then this photo should be copied directly to family (if I have wifi). If I don't have have wifi, this photo should be immediately copied to `t` in which case I have two copies of the file on my tablet (I think)? If I delete the photo from the crippled filesystem `c` I still have the one that was already copied to `t`. If I re-connect to wifi, perhaps the photo will get sent to `family` from `t`. It might stay in `t` since it is missing from `c`, not sure how this would work (but anyhow, see archive folders in the next paragraph).
|
||||
|
||||
Maybe I want to save some space on my tablet (deleting from photo app might work?, but archiving is more likely to work). So I open up my photo app, browse to my `c` folder and start putting a bunch of files in a sub-folder named `archive`. They are then immediately deleted from my tablet (unless they were never synced to `family` in which case I have two copies of them, so I would still have a copy sitting in transfer `t`). If I archive files when I have no wifi, presumably they will just get moved to `t` by assistant since git-annex cannot verify the copy at `family`?
|
||||
|
||||
Would something like that work for your use case? I don't actually use Android termux, so I am sure others might have some insight into use of the various directories.
|
||||
|
||||
—Andrew
|
||||
"""]]
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="andrew"
|
||||
avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
|
||||
subject="use case"
|
||||
date="2018-05-22T19:20:24Z"
|
||||
content="""
|
||||
Hmmm. Could you talk more about your use case “The use case I have in mind is syncing photos to an Android tablet in a v5 repository.”?
|
||||
|
||||
Lets say I have a nice collection of family photos on my desktop computer annexed in a folder called family. Lets say we have `numcopies` set at 1. I keep only the best photos, so it always about 1gb. In the family folder I have nice organized sub-folders and I add new images occasionally. I have an Android tablet that sits on my coffee table and I want visitors to be able to open the tablet, run some gallery app and view all my family photos. Sometimes i'll grab the tablet and take it with me to family gatherings, so I want all the photos on in, ready for offline viewing.
|
||||
|
||||
With this use case, perhaps I run assistant inside termux. I clone family into `/data/data/com.termux/files/home` set it as standard group `transfer` and call it `t`, I also clone it into `/storage/emulated/0`, set it as standard group client, and call this crippled client repo `c`. Our `c` folder should now be accessible to any Android photo gallery app. As we make changes to family, on our desktop, assistant on the Android tablet brings them in, when we have wifi, it will probably copy them directly to `c`?
|
||||
|
||||
If I take a photo on my tablet, put it in the `c` directory (which is accessible from my photo app), then this photo should be copied directly to family (if I have wifi). If I don't have have wifi, this photo should be immediately copied to `t` in which case I have two copies of the file on my tablet. If I delete the photo from the crippled filesystem `c` I still have the one in `t`. If I re-connect to wifi, perhaps the photo will get sent to family.
|
||||
|
||||
Maybe I want to save some space on my tablet. So I open up my photo app, browse to my `c` folder and start putting a bunch of files in a sub-folder named `archive`. They are immediately deleted from tablet (unless they were never synced to `family` in which case I have two copies of them, so still have a copy sitting in `transfer`). If I delete files when I have no wifi, presumably they will just get copied to `t` since git-annex cannot verify the copy at `family`?
|
||||
|
||||
Would something like that work for your use case Joey?
|
||||
|
||||
—Andrew
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="andrew"
|
||||
avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
|
||||
subject="comment 2"
|
||||
date="2018-05-22T19:22:26Z"
|
||||
content="""
|
||||
Oh, I am not sure why I assumed Joey wrote that forum post…
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://christian.amsuess.com/chrysn"
|
||||
nickname="chrysn"
|
||||
avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
|
||||
subject="Re: use case"
|
||||
date="2018-05-23T07:56:34Z"
|
||||
content="""
|
||||
The particular repository I'm looking at for a first stage is a wedding photo repository. It contains both the working directories of the photographers involved (some JPEG, some RAW-based with git-versioned Makefiles and sidecars to get the JPEGs which are then checked in with numcopies=0), where some photographers have their files in multiples copies to reflect their pre-sorting. The final photos are also copied to a release directory in various combinations (\"complete couple's selection\", \"pictures released to guests\", \"other pictures of guests\") which were then distributed by a process outside of git-annex' control (zip files were created and distributed over a web server).
|
||||
|
||||
This copying workflow usually works greatly with git-annex v5 (or v6 when files are always kept locked): even if files were checked in by different contributors with different default hash settings, copying a file means copying a symlink.
|
||||
|
||||
The whole repository amounts to 125gb, with 3gb in the selection.
|
||||
|
||||
On the tablet, when I clone the repository on the crippled side of the file system, the initial checkout takes quite some time, and the 3gb get blown to 8gb due to the file being copied not only to the \"complete couple's selection\", but also to the other selections and the occasional picture in the photographers' directories.
|
||||
|
||||
Note that on this repository, the tablet does not even have write access to the repository. It is set to untrusted and \"wants\" the selection folder.
|
||||
|
||||
---
|
||||
|
||||
The next repository I'd like to do this with is our family photo repository, containing an average of four persons' digitized analog and digital photos starting in 2002 and contains about 700gb of images; that repository has not that much duplication, but the interesting files (often a \"Selection\" folder per event that contains copies with appropriately named files for a sequence) are still checked in in duplicate.
|
||||
"""]]
|
||||
Loading…
Reference in a new issue