Added a comment

This commit is contained in:
zardoz 2014-07-11 11:46:08 +00:00 committed by admin
parent 3355275161
commit 089a23b291

View file

@ -0,0 +1,44 @@
[[!comment format=mdwn
username="zardoz"
ip="134.147.14.84"
subject="comment 2"
date="2014-07-11T11:46:08Z"
content="""
Yes, youre probably right that the benefit of this is slim when the
watching daemon auto-adds new files. So the «status» output would
never change and show the status that upheld before starting the
daemon.
The reason I brought this up that I recall reading a comment of yours
somewhere on the site, to the effect that the assistant can sometimes
speed up certain operations, because it can make certain valid
assumptions on the state of the repo due to the fact that the
assistant has been monitoring it. I dont recall what those operations
were, though. Thats why it occurred to me whether there might be a
daemon that just monitors via inotify, and neither adds nor syncs, and
only provides information to certain commands to speed things up under
some circumstances.
In general, is it accurate to say that git-annex mostly takes the
«space» option when making a space/time-trade-offs? I noticed that the
memory consumption is really slim most of the time, and wondered
whether there might be options of speeding operations up by relying on
more memory instead (perhaps also doing persistent caching). On the
other hand, in some regards you are probably committed to the
time/memory trade-offs taken by vanilla git, so maybe theres not much
room for improvement, git-annex wise…
Maybe direct-mode repos on the order of 100ks of files are just not
practical. Im using indirect mode for my really big repos now, and
its now responsive enough to use (except for «annex unused», which is
inherently expensive, as you once explained). At least commiting wont
take tens of minutes that way. Ill just have to make the software
play nicely with the symlinks.
BTW, the file-system seems to have a huge impact on this. My large
direct mode annex is practically unusable on ext (tens of minutes per
commit), but still usable on btrfs (a few minutes). Im migrating one
disk to btrfs at home and will do some controlled benchmarks then. The
added bonus is that directories dont always take up a full block.
"""]]