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

3 files changed, 30 insertions, 0 deletions

diff --git a/doc/bugs/Merge_involving_symlink_yields_unexpected_results/comment_4_13179e0f72026092e48c13082818ce68._comment b/doc/bugs/Merge_involving_symlink_yields_unexpected_results/comment_4_13179e0f72026092e48c13082818ce68._comment
new file mode 100644
index 000000000..49210ee55
--- /dev/null
+++ b/doc/bugs/Merge_involving_symlink_yields_unexpected_results/comment_4_13179e0f72026092e48c13082818ce68._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="analysis"
+ date="2014-07-08T17:52:59Z"
+ content="""
+When resolveMerge' calls graftin to add A's file2 symlink to B's tree, it actually stages the right symlink (the non-annexed one).
+
+However, the work tree is left as-is, so it still has the annexed symlink in it. So git status shows file2 as modified. Later syncs will commit that.
+
+This is why the sync in A doesn't have the problem, as there things are the other way around, and git-annex makes the git-annex symlink, leaving the non-annexed symlink as-is in the work tree.
+
+So, graftin needs to update the work tree. But it's tricky because graftin is called in 3 situations: non-symlink file, directory, and non-annexed symlink.
+Interestingly, in the other 2 cases, git-merge already takes care of updating the work tree -- it deletes the annexed symlink and puts in place either the non-symlink file or the directory. It's only the the case of a merge conflict involving 2 symlinks that git merge doesn't update the tree in this way. It's nice to be able to rely on git-merge in the other 2 cases, especially the directory case (avoids having to manually check out the directory).
+"""]]
diff --git a/doc/forum/__171__Locking__187___files_until_synced.mdwn b/doc/forum/__171__Locking__187___files_until_synced.mdwn
new file mode 100644
index 000000000..129927bdc
--- /dev/null
+++ b/doc/forum/__171__Locking__187___files_until_synced.mdwn
@@ -0,0 +1,7 @@
+I’m currently trying to set up a sync which involves an SQLite3 database file that should always be in the same state on all systems at all times (since there is no readily available way of merging the data). Basically, I’m looking for a practical way that gives me some help in making sure the files never drift apart between my remotes. Since I’m forgetful and might forget syncing the repo before going home from the office, I was wondering whether there might be a good way to assist me in this. Has anyone had some good ideas in this direction, or is there a canonical solution?
+
+It occurred to me one way would be to instate a hook somewhere that links the database to /dev/null in all other remotes (so the software will fail to work if I start it without having synced), but it seems tricky. I guess would have to involve per-remote branches, which will be hard to do, since I need to use direct mode.
+
+A less complex method might be forcing a sync before shutting down the system resp. when booting up.
+
+Maybe other folks have had ideas for a practical, yet robust solution.
diff --git a/doc/forum/__171__Locking__187___files_until_synced/comment_1_8bf59f47fee0a8d5741fe209b5899863._comment b/doc/forum/__171__Locking__187___files_until_synced/comment_1_8bf59f47fee0a8d5741fe209b5899863._comment
new file mode 100644
index 000000000..d327a58b4
--- /dev/null
+++ b/doc/forum/__171__Locking__187___files_until_synced/comment_1_8bf59f47fee0a8d5741fe209b5899863._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 1"
+ date="2014-07-08T17:31:53Z"
+ content="""
+This is something git's distributed nature preludes. You might frankly be better with one of the centralized VCSs that supports locking in this specific case. Or, you can do some kind of \"lock server\" that the clients contact, layering a centralized approach on top of git.
+"""]]