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

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

Browse source
This commit is contained in:
Joey Hess 2015-01-27 17:39:03 -04:00
commit 399f7904d7
3 changed files with 37 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/design/assistant/polls/prioritizing_special_remotes.mdwn
View file

@ -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

24
doc/design/v6/comment_2_8f35254d2cd5d0c273d5392ddd857c2d._comment Normal file
View file

@ -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.
"""]]

12
doc/install/Ubuntu/comment_14_b511063001af2e2170bef657cf016ff2._comment Normal file
View file

@ -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>
"""]]