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

Added a comment

Browse source
This commit is contained in:
forums+git-annex@d2ec818a5e37440c45fa5f3cbd82fe5110b32020 2019-09-13 23:17:37 +00:00 • committed by admin
parent 91caba25be
commit 3c6ebf69ae
1 changed files with 19 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
doc/todo/remote-ready-command/comment_2_0e79b93a9c614a259b9a7d7c1f6cb6dc._comment Normal file
View file

@ -0,0 +1,19 @@
[[!comment format=mdwn
username="forums+git-annex@d2ec818a5e37440c45fa5f3cbd82fe5110b32020"
nickname="forums+git-annex"
avatar="http://cdn.libravatar.org/avatar/b6fde94dbf127b822f7b6109399d50c9"
subject="comment 2"
date="2019-09-13T23:17:37Z"
content="""
> I wonder, what about downloads from the remote, those could also overload some remote.
That is a good point, but it's not needed for my use case; KBFS hasn't had any trouble so far keeping up with reading data, only with writing.
> Is your KBFS remote an external special remote, or are you just using a directory special remote on that filesystem? If it were an external special remote, you could just make it delay until ready when it receives a TRANSFER request.
I originally had a directory special remote pointing to the FUSE-mounted KBFS, but I was having some issues with that, so I switched to an rsync special remote (also pointing to FUSE-mounted KBFS).
> (BTW, the solution to each git-annex copy creating a git-annex branch commit is annex.alwayscommit=false. Or perhaps usng --batch to drive a single copy command.)
Awesome, looks like either of those would be better workarounds than I have right now. Thanks!
"""]]