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

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

Browse source
This commit is contained in:
Joey Hess 2019-10-01 16:05:15 -04:00
commit d7f4bb5462
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 28 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
doc/bugs/remotedaemon_--stop_doesn__39__t_work/comment_2_a50a5c1337f204d889a6f50631691d1a._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
nickname="branchable"
avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
subject="comment 2"
date="2019-09-30T22:25:11Z"
content="""
Given that there is one remotedaemon process per repository, if a user has (say) 10 of them running and wants to stop a particular one, what is the expectation of how they would do this? Presumably it would involve something like searching the process table for a remotedaemon process whose cwd is the repository in question. I can't think of any trivial one-liner to do this, since the usual suspects like `pkill` / `ps` / `pidof` etc. do not support filtering by cwd.
So an advantage of implementing pidfiles and `--stop` would be that each user doesn't have to worry about such details.
"""]]

17
doc/todo/wishlist__58___disable_automatic_commits/comment_3_53b1321d5bcaf4139f9fbbd17f26fe75._comment Normal file
View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
nickname="branchable"
avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
subject="There are still benefits to commit throttling"
date="2019-09-30T22:16:10Z"
content="""
> The assistant does not commit files that are open for write.
Interesting; I see it uses lsof for this.
> So unless ffmpeg partially writes the file, then closes the file, then reopens it and writes some more, the assistant will only make a single commit.
OK, so that probably wasn't a good example. But that still doesn't negate my TODO list editing example, and it is not hard to think of other scenarios where partial results are written by one process and then rewritten in-place by another.
It also doesn't negate the fact that throttling the commit speed would also help reduce I/O between remotes in some cases simply by reducing \"churn\" within any given repo, as noted in [my comment on design/assistant/rate_limiting](https://git-annex.branchable.com/design/assistant/rate_limiting/#comment-c88bc709792c79037a41292c1db70889).
"""]]