minor typo fixes throughout
problematic flexibility
This commit is contained in:
parent
4fd28807c1
commit
64e844e1fe
19 changed files with 22 additions and 22 deletions
|
@ -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.
|
||||
"""]]
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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>
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue