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

minor typo fixes throughout

Browse source 
problematic
flexibility
This commit is contained in:
Yaroslav Halchenko 2016-06-01 21:46:58 -04:00 • committed by Joey Hess
parent 4fd28807c1
commit 64e844e1fe
Failed to extract signature
19 changed files with 22 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment
View file

@ -21,5 +21,5 @@ The MSDN article has one very interesting bit:
(It seems that, when using that prefix, `/` is not converted to `\` .. I think git-annex is quite good about getting the slashes the right way round these days.)
So it might be possible for git-annex to use that prefix and avoid this issue entirely. Haskell's FilePath library does understand that prefix (treats it as part of the drive). Since git-annex always uses the path to the top of the Repo when constructing the problimatic FilePaths, I might be able to just change the Repo constructor to add that prefix, and everything follow from that. I tried doing that, unfortunately this makes *git* fail, with \"fatal: relative path syntax cannot be used outside working tree\" when operating on such a repo. Cause git doesn't understand that prefix.
So it might be possible for git-annex to use that prefix and avoid this issue entirely. Haskell's FilePath library does understand that prefix (treats it as part of the drive). Since git-annex always uses the path to the top of the Repo when constructing the problematic FilePaths, I might be able to just change the Repo constructor to add that prefix, and everything follow from that. I tried doing that, unfortunately this makes *git* fail, with \"fatal: relative path syntax cannot be used outside working tree\" when operating on such a repo. Cause git doesn't understand that prefix.
"""]]

4
doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment
View file

@ -34,11 +34,11 @@ The only option on the git-annex side would be to add an option to totally
disable use of locks, which would make it rather unsafe to use.
Or to use only dotlocks (file existence level locks).
Dotlocks are problimatic. Some of the uses git-annex makes of locking,
Dotlocks are problematic. Some of the uses git-annex makes of locking,
like using both shared and exclusive locks on a file to let multiple
concurrent readers, would be very hard to emulate with dotlocks. Also,
dotlocks go stale when processes die, and git-annex uses lots of different
locks in different places, which would be problimatic to clean up in such
locks in different places, which would be problematic to clean up in such
a situation.
I think that it might make sense, if git-annex has to fall back to dotlocks,

2
doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment
View file

@ -11,7 +11,7 @@ joeyh so, my thought is that perhaps you had a git-annex process before that was
joeyh for example, if you ran it and ctrl-z'd at just the right time, it could be suspended and holding the lock
joeyh (or the kernel coud have gotten confused, which given you also had a crash, who knows..)
dp sounds logical
joeyh forcing locks is always a problimatic thing
joeyh forcing locks is always a problematic thing
joeyh but git-annex could certainly notice if it seems to be stalled and print some useful messages
joeyh and maybe have a way to run with locks forced
</pre>