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

3 files changed, 37 insertions, 1 deletions

diff --git a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
index 5dccfca66..3c9de2b02 100644
--- a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
+++ b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
@@ -6,7 +6,7 @@ locally paired systems, and remote servers with rsync.
 Help me prioritize my work: What special remote would you most like
 to use with the git-annex assistant?
 
-[[!poll open=yes 16 "Amazon S3 (done)" 12 "Amazon Glacier (done)" 10 "Box.com (done)" 74 "My phone (or MP3 player)" 25 "Tahoe-LAFS" 13 "OpenStack SWIFT" 35 "Google Drive"]]
+[[!poll open=yes 18 "Amazon S3 (done)" 12 "Amazon Glacier (done)" 10 "Box.com (done)" 74 "My phone (or MP3 player)" 25 "Tahoe-LAFS" 13 "OpenStack SWIFT" 35 "Google Drive"]]
 
 This poll is ordered with the options I consider easiest to build
 listed first. Mostly because git-annex already supports them and they
diff --git a/doc/design/v6/comment_2_8f35254d2cd5d0c273d5392ddd857c2d._comment b/doc/design/v6/comment_2_8f35254d2cd5d0c273d5392ddd857c2d._comment
new file mode 100644
index 000000000..ef050ac93
--- /dev/null
+++ b/doc/design/v6/comment_2_8f35254d2cd5d0c273d5392ddd857c2d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="comment 2"
+ date="2015-01-26T19:46:12Z"
+ content="""
+\"... merging repo A(v5) into repo B(v6)? This seems like it would be all to easy for a user to do.\"
+
+it would be easy if two separate repos are inited separately of different versions and then merged.  But how frequent could such situation arise?  I  don't think that it is not that common actually in non git-annex assistant initialized  repositories, especially if \"v6\" (or some other custom) layout would be non-default.
+
+This also somewhat reflects upon \"When it's receiving an object into a mixed v5 and v6 repo, it can't know which location that repo expects the object file to be located in.\" -- how plausible/frequent would be to see a mixed v5/6 repo?
+
+\".annex-version flag file\" -- I think it is a good idea.  (may be even better an .annex/version directory/file to reserve for possibly future other branch-specific, thus not for git-annex branch additions).  Indeed it would take time for repos to acquire it, but imho it is ok, if added automagically by new git-annex versions.  Also it is a tiny price to pay for users who do not really care about \"living on the edge\".    But it also might better be coupled with having git-annex:version (i.e. version file under git-annex branch) describing layout of the git-annex branch since those two are somewhat independent, right?
+
+Also a wild idea to mitigate inconvenience for users happen they migrate repositories from old to new formats: to provide 'git annex compat-layout  [version]' command which, for files with content, would  generate symlinks to files in new format to locations in old, with some command to clean them up  later on (e.g. 'git annex compat-layout --cleanup'). Although inefficient per-se it could be a big convenience since would eliminate need to \"migrate/rewrite\" entire history, while still making it possible to get access to previous versions.  With a handling in hooks could be automated to even hide that from users entirely.  or is there a big culprit I don't see?
+
+
+\"version numbers vs configuration\"
+
+having flexibility of configurations, possibly with versions simply providing enumerations to some of them, might be a great feature to have in the long run.  Not sure though if it would not blow up complexity :-/
+
+Overall -- if complete transition to improved/unified v6 is too big of undertaker, allowing for custom non-default configurations while sticking to v5 as the default one and forbidding merges between different versions, could be sufficient to scale up for atypical large uses.  If everyone to migrate to v6 -- more optimal layout should be well thought through to be worthwhile undertaking.
+
+"""]]
diff --git a/doc/install/Ubuntu/comment_14_b511063001af2e2170bef657cf016ff2._comment b/doc/install/Ubuntu/comment_14_b511063001af2e2170bef657cf016ff2._comment
new file mode 100644
index 000000000..472ff6730
--- /dev/null
+++ b/doc/install/Ubuntu/comment_14_b511063001af2e2170bef657cf016ff2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawltxdgYMUK4CMJh3jC8AlegwyoiHA9Ka7o"
+ nickname="Justin"
+ subject="Trusty PPA"
+ date="2015-01-27T18:24:50Z"
+ content="""
+@Dennis, I just got a backport of the latest release (5.20150113) running under trusty.  This was my first attempt at backporting software and it ended up being a fairly big project.  I had to pull in a lot of haskell dependencies from vivid in order to get this to build.
+
+I'll attempt to keep this PPA up-to-date as long as I don't have to do too much more build dep wrangling.
+
+<https://launchpad.net/~jtgeibel/+archive/ubuntu/ppa?field.series_filter=trusty>
+"""]]