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

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

Browse source
This commit is contained in:
Joey Hess 2014-08-13 11:07:44 -04:00
commit a4e15a7cf2
3 changed files with 56 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

23
doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn Normal file
View file

@ -0,0 +1,23 @@
This is a follow-up to [this
qbug](http://git-annex.branchable.com/bugs/WORM_keys_differ_depending_on_working_dir_during_add/).
Thank you for your fix there! However, if I understood correctly, you
indicated in your reply that the current fix completely removes the
relative path component from WORM keys. I gave some thought to this
and believe not having the relative path encoded inside WORM keys
makes key collisions (and accordingly data-loss) a very dire problem,
while they are not of practical concern if the relative path is
encoded.
When relative paths are encoded within the key, a collision can only
occur when a file in the same directory is annexed twice within the
resolution of the mtime component inside the key (i.e., one second).
As such, unless one adds files automatically with a period of < 1s,
one can very much be certain that no collisions come up.
Without relative paths, however, one could never be certain that
adding a file will not result in data-loss.
Instead of just using the basename, WORM keys could be kept stable by
using the relative path and anchoring it to the root of the
repository.

10
doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://svario.it/gioele"
nickname="gioele"
subject="comment 3"
date="2014-08-13T06:36:52Z"
content="""
This is strange: I can replicate the problem on three different Ubuntu machines (12.04.5 32 and 64 bit, 14.04 64 bit) using that script.
I attached to the gist [the execution log in direct mode](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-annex-direct-log) (where the bug is shown), the [log in indirect mode](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-annex-indirect-log) (where the bug does not appear), and a [diff between the two](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-log-diff). I hope this helps.
"""]]

23
doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="http://svario.it/gioele"
nickname="gioele"
subject="comment 4"
date="2014-08-13T06:40:12Z"
content="""
Talking about the three possible causes for this bug,
> 1) pc1 has not pushed git-annex branch to origin (or pushed it after pc2 pulled)
pc1 pushes using `git annex sync -c annex.alwayscommit=true origin`. This should be enough, isn't it?
> 2) pc2 has not fetched git-annex branch from origin
The pc2 repository is created with `git clone localhost:/tmp/annex/Docs.git`, so there branches should all be there. I tried adding a `git fetch --all` to the script but it makes no difference. This is the list of branches in pc2:
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/synced/git-annex
remotes/origin/synced/master
"""]]