Typo fix unncessary -> unnecessary.
Detected while reading recent CHANGELOG entry but then decided to apply to entire codebase and docs since why not?
This commit is contained in:
parent
f091eff476
commit
0151976676
43 changed files with 60 additions and 60 deletions
|
@ -10,6 +10,6 @@ unmounted and remounted for some reason in between the two steps of the
|
|||
import would explain the behavior.
|
||||
|
||||
Note that I've opened
|
||||
[[todo/import_tree_from_FAT_does_unncessary_work_due_to_inode_instability]]
|
||||
[[todo/import_tree_from_FAT_does_unnecessary_work_due_to_inode_instability]]
|
||||
after thinking of some other consequences of this.
|
||||
"""]]
|
||||
|
|
|
@ -15,5 +15,5 @@ Fixed that. Which leaves 2 open questions:
|
|||
|
||||
Although the answer to the second question doesn't matter much if the
|
||||
data loss bug is fixed -- if there's a problem of some kind causing
|
||||
unncessary repairs, it would only be some excess CPU load.
|
||||
unnecessary repairs, it would only be some excess CPU load.
|
||||
"""]]
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
If the assistant crashed in the middle of a repair that confirms my
|
||||
analysis, and my fix will avoid both the data loss problem *and* the crash.
|
||||
|
||||
Only remaining question to me is why would it trigger an unncessary repair.
|
||||
Only remaining question to me is why would it trigger an unnecessary repair.
|
||||
|
||||
But that could be anything that causes git fsck to exit nonzero. Or it
|
||||
might be that git fsck found an actual problem, but not one that was
|
||||
|
|
|
@ -8,5 +8,5 @@ more times than necessary. Also was able to avoid updating the git-annex
|
|||
branch, which eliminates several calls to git (depending on the number of
|
||||
remotes). On Linux, this made it 25% faster. Might be more on Windows.
|
||||
|
||||
Rest of the strace looks clean, nothing else stands out as unncessary.
|
||||
Rest of the strace looks clean, nothing else stands out as unnecessary.
|
||||
"""]]
|
||||
|
|
|
@ -15,7 +15,7 @@ files it received to other remotes, and to do that it needs to check if
|
|||
their content is present. Which is normally inexpensive, so not a problem.
|
||||
|
||||
It so happens that sync calls inAnnex even when
|
||||
there are no other remotes to send the content to. Which is unncessary, and
|
||||
there are no other remotes to send the content to. Which is unnecessary, and
|
||||
avoiding that could be used to fix this problem. But there would still be a
|
||||
problem if there were some other remote that the content ought to be sent to,
|
||||
if it still called inAnnex in that case. Maybe it's possible to avoid it calling
|
||||
|
|
|
@ -14,5 +14,5 @@ the timestamps of anything in the git repo.
|
|||
|
||||
Now, if Android is varying the mtime it reports for files, so resulting in
|
||||
a changed CID, it may be that would cause an import of content it had already
|
||||
imported before, and maybe that leads to the unncessary commit.
|
||||
imported before, and maybe that leads to the unnecessary commit.
|
||||
"""]]
|
||||
|
|
|
@ -11,7 +11,7 @@ Essentially the same problem as
|
|||
(And also the main problem using git-annex on Windows in WSL.)
|
||||
|
||||
Not a great deal I can do about this, because the locking is in sqlite.
|
||||
That other bug has some thoughts about avoiding unncessary use of sqlite
|
||||
That other bug has some thoughts about avoiding unnecessary use of sqlite
|
||||
or moving the databases to some other filesystem.
|
||||
|
||||
It may be that not enabling WAL mode on the database would change sqlite's
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
subject="""comment 2"""
|
||||
date="2020-06-11T19:26:05Z"
|
||||
content="""
|
||||
This does seem to be an unncessary use of the database,
|
||||
This does seem to be an unnecessary use of the database,
|
||||
git-annex init always creates the db in scanUnlockedFiles
|
||||
when the repo has a HEAD ref, but normally it will find no unlocked files
|
||||
and so it could just not create the database there.
|
||||
|
|
|
@ -95,4 +95,4 @@ Besides reporting the issue, I also have a question: could I just rerun `export
|
|||
[[!meta author=yoh]]
|
||||
[[!tag projects/datalad]]
|
||||
|
||||
> [[fixed|done]] bypassed this unncessary locking for exports. --[[Joey]]
|
||||
> [[fixed|done]] bypassed this unnecessary locking for exports. --[[Joey]]
|
||||
|
|
|
@ -23,5 +23,5 @@ Thinking about this over the weekend, I had two ideas:
|
|||
Seems likely that only 2 or 3 in the cat-file pool will
|
||||
maximise concurrency, because it's not a major bottleneck most of the
|
||||
time, and when it is the actual bottleneck is probably disk IO and so
|
||||
won't be helped by more (and likely more only increase unncessary seeks).
|
||||
won't be helped by more (and likely more only increase unnecessary seeks).
|
||||
"""]]
|
||||
|
|
|
@ -20,7 +20,7 @@ so it re-smudges the work tree file unncessarily.
|
|||
I have not been able to find a number of files to drop that replicates
|
||||
the bug report. When a lot of files are dropped, it starts taking
|
||||
sufficiently long to update the index file that it ends up with a newer
|
||||
timestamp, which avoids the unncessary additional smudging. The worse
|
||||
timestamp, which avoids the unnecessary additional smudging. The worse
|
||||
case I have found here is dropping 9 files causes all 9 to get re-smudged,
|
||||
but that's not enough to get git to use the progress display.
|
||||
"""]]
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
content="""
|
||||
Anyway, if git-annex could preserve the mtime of an unlocked file when
|
||||
writing its pointer file or when populating it with content, that would
|
||||
avoid the unncessary smudging. (Which seems better than adding a delay when
|
||||
avoid the unnecessary smudging. (Which seems better than adding a delay when
|
||||
updating the index file, or setting the index's mtime ahead of the current
|
||||
time..)
|
||||
|
||||
|
@ -14,6 +14,6 @@ with annex.thin the content is a hard link and it would probably not be
|
|||
good to change its mtime.
|
||||
|
||||
For now, I didn't do it extensively, but only in depopulatePointerFile.
|
||||
That was enough to eliminate the unncessary smudging after drop that I was
|
||||
That was enough to eliminate the unnecessary smudging after drop that I was
|
||||
seeing.
|
||||
"""]]
|
||||
|
|
|
@ -4,7 +4,7 @@ When annex.numcopies is 4, and there are only 4 copies of a file,
|
|||
drop me (locking a2...) (locking a3...) (locking a4...) (unsafe)
|
||||
Could only verify the existence of 3 out of 4 necessary copies
|
||||
|
||||
That is unncessary work, because the drop cannot possibly succeed when
|
||||
That is unnecessary work, because the drop cannot possibly succeed when
|
||||
there are not more than numcopies. It should be able to skip locking the
|
||||
content on remotes and immediately fail.
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue