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

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2021-04-20 15:18:56 -04:00
commit 5dae95f95f
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 53 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

26
doc/forum/Getting_started_with_local_multi-device_file_sync..mdwn Normal file
View file

@ -0,0 +1,26 @@
Hello everyone.
I’m new to local multi-device file sync, and I just read the project overviews and FAQs as well as most of the documentations of **git-annex**, **Mutagen**, **Syncthing**, and **Unison**. I’m a little stuck in thinking everything through until the end, so maybe I could ask some of you for your advice and/or opinion.
—
## What do I want to achieve?
Synchronized folders and files as well as symlinks. LAN-only preferred, no online/cloud, i.e. everything should, if possible, work without any internet connection whatsoever.
## How many and which devices are in use?
Three, at least. We’re having three Mac devices in our network, as well as optionally a Raspberry Pi with optionally some storage attached that could serve as network storage (SSHFS, NFS, AFP, et cetera) and serve files between the Mac devices; also an Apple Time Capsule with 2 TB storage would be available.
## Is real-time synchronization necessary?
Not really; it would be okay to be automating, i.e. auto-starting, the check/sync for example every hour. I think this is one of the main differences of Syncthing and Unison, that Unison needs to be “started” manually after making changes to files, and Syncthing just runs in the background and as soon as something is changed, the changes are propagated to all other devices?
## Are the devices used at the same time?
Generally, I’d like to say no. In the very most cases the three Mac devices are not used at the same moment in time.
## Are all devices always-on?
Not really. The Mac devices (old Macbook, new Macbook, Mac Mini) are often in sleep mode, I guess; the Raspberry Pi on my network is always-on, though.
—
In case I haven’t forgotten to write anything down, I think that’s all I have to say, i.e. am asking/looking for. Based on these demands, what would you say would be the better way to go, and if you don’t mind, please elaborate why?
Thank you so much, everyone.

12
doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_4_4dbb0b18905d30ae6b187745859e75c2._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
subject="comment 4"
date="2021-04-20T18:30:39Z"
content="""
Perhaps Git Annex could have first-class support for a local special remote inside the .git/annex dir where files that aren't checked out are stored in a more efficient manner.
This would mainly be useful for old versions of files you want to keep in the repo but don't need immediate access to or bare repos like in OP's case. Once special remotes support compression, it might make sense to make it the default storage method for bare repos actually.
Ideally these could be set to be any local special remote backend; bup would make an ideal candidate for storing old versions of documents efficiently for example.
Having files in this such a \"local special remote\" would then be equivalent to having them in the regular .git/annex/objects dir for tracking purposes.
"""]]

15
doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_3_d4672f72a00509186cfc5dd85e1da140._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
subject="comment 3"
date="2021-04-20T18:05:27Z"
content="""
Would it perhaps be possible to set the compression using filters like file name/extension?
For example, I wouldn't want GA to waste time on compressing multimedia files that are already at entropy and, since they make up the majority of my special remote's content, re-writing them would be very time intensive (even more so when remote solutions are involved).
Certain compressors might also work better on some files types compared to others.
This could be very important to scientists using datalad as they are likely to A. be working very specific kinds of data where certain compressors might significantly outperform others and B. have large quantities of data where compression is essential.
If compressors are going to be limited to a known-safe selection, an important aspect to keep in mind would be compression levels as some compressors like zstd can range from lzo-like performance characteristics to lzma ones.
Definitely a +1 on this one though, it would be very useful for my use-case aswell.
"""]]