diff options
31 files changed, 337 insertions, 10 deletions
diff --git a/Remote/S3.hs b/Remote/S3.hs index 7dbd096f7..63666bc29 100644 --- a/Remote/S3.hs +++ b/Remote/S3.hs @@ -213,9 +213,11 @@ s3Action r noconn action = do bucketFile :: Remote -> Key -> FilePath bucketFile r = munge . key2file where - munge s = case M.lookup "mungekeys" $ fromJust $ config r of - Just "ia" -> iaMunge s - _ -> s + munge s = case M.lookup "mungekeys" c of + Just "ia" -> iaMunge $ prefix ++ s + _ -> prefix ++ s + prefix = M.findWithDefault "" "fileprefix" c + c = fromJust $ config r bucketKey :: Remote -> String -> Key -> S3Object bucketKey r bucket k = S3Object bucket (bucketFile r k) "" [] L.empty diff --git a/debian/changelog b/debian/changelog index 5fcd82626..a5a1f1134 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,9 +1,10 @@ git-annex (3.20120808) UNRELEASED; urgency=low + * S3: Add fileprefix setting. * init: If no description is provided for a new repository, one will automatically be generated, like "joey@gnu:~/foo" - -- Joey Hess <joeyh@debian.org> Tue, 07 Aug 2012 13:35:07 -0400 + -- Joey Hess <joeyh@debian.org> Thu, 09 Aug 2012 13:51:47 -0400 git-annex (3.20120807) unstable; urgency=low diff --git a/doc/backends/comment_1_375bb1fb5973e8fa67b763f2dd6e404b._comment b/doc/backends/comment_1_375bb1fb5973e8fa67b763f2dd6e404b._comment new file mode 100644 index 000000000..dc178a6fe --- /dev/null +++ b/doc/backends/comment_1_375bb1fb5973e8fa67b763f2dd6e404b._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="http://nanotech.nanotechcorp.net/" + nickname="NanoTech" + subject="SHA performance" + date="2012-08-10T04:37:32Z" + content=""" +It turns out that (at least on x86-64 machines) `SHA512` [is faster than][1] `SHA256`. In some benchmarks I performed<sup>1</sup> `SHA256` was 1.8–2.2x slower than `SHA1` while `SHA512` was only 1.5–1.6x slower. + +`SHA224` and `SHA384` are effectively just truncated versions of `SHA256` and `SHA512` so their performance characteristics are identical. + +[1]: https://community.emc.com/community/edn/rsashare/blog/2010/11/01/sha-2-algorithms-when-sha-512-is-more-secure-and-faster +<sup>1</sup> `time head -c 100000000 /dev/zero | shasum -a 512` +"""]] diff --git a/doc/design/assistant/blog/day_49__first_run_experience.mdwn b/doc/design/assistant/blog/day_49__first_run_experience.mdwn index 08ba462d4..7aa2071e8 100644 --- a/doc/design/assistant/blog/day_49__first_run_experience.mdwn +++ b/doc/design/assistant/blog/day_49__first_run_experience.mdwn @@ -31,7 +31,7 @@ Time for the first of probably many polls! What should the default directory name used by the git-annex assistant be? -[[!poll open=no 19 "Annex" 7 "GitAnnex" 10 "Synced" 0 "AutoSynced" 1 "Shared" 10 "something lowercase!" 1 "CowboyNeal" 1 "Annexbox"]] +[[!poll open=no 19 "Annex" 7 "GitAnnex" 1 "~/git-annex/" 10 "Synced" 0 "AutoSynced" 1 "Shared" 10 "something lowercase!" 1 "CowboyNeal" 1 "Annexbox"]] (Note: This is a wiki. You can edit this page to add your own [[ikiwiki/directive/poll]] options!) diff --git a/doc/design/assistant/blog/day_52__file_browser/comment_1_cd000c2d56b60cc1f17b221322a32aa7._comment b/doc/design/assistant/blog/day_52__file_browser/comment_1_cd000c2d56b60cc1f17b221322a32aa7._comment new file mode 100644 index 000000000..206b0c70e --- /dev/null +++ b/doc/design/assistant/blog/day_52__file_browser/comment_1_cd000c2d56b60cc1f17b221322a32aa7._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://cweiske.de/" + nickname="cweiske" + subject="comment 1" + date="2012-08-15T22:02:14Z" + content=""" +I thought that most (if not all) browsers prevent opening local files/directories via web pages. How did you solve that problem? +"""]] diff --git a/doc/design/assistant/blog/day_52__file_browser/comment_2_21d1da67cf9105a545583ba2302c10fb._comment b/doc/design/assistant/blog/day_52__file_browser/comment_2_21d1da67cf9105a545583ba2302c10fb._comment new file mode 100644 index 000000000..9ba5104e2 --- /dev/null +++ b/doc/design/assistant/blog/day_52__file_browser/comment_2_21d1da67cf9105a545583ba2302c10fb._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + subject="comment 2" + date="2012-08-16T23:34:12Z" + content=""" +Yes, it's surprising to me when I see it work, and I wrote it. :) Since git-annex is running locally on the same system as the browser, it can open the file manager when the user clicks on a link in the web browser. To the web browser, this is just an AJAX request. +"""]] diff --git a/doc/design/assistant/blog/day_56__transfer_control.mdwn b/doc/design/assistant/blog/day_56__transfer_control.mdwn new file mode 100644 index 000000000..1ce926897 --- /dev/null +++ b/doc/design/assistant/blog/day_56__transfer_control.mdwn @@ -0,0 +1,8 @@ +A bit under the weather, but got into building buttons to control running +and queued transfers today. The html and javascript side is done, with +each transfer now having a cancel button, as well as a pause/start button. + +Canceling queued transfers works. Canceling running transfers will +need some more work, because killing a thread doesn't kill the processes +being run by that thread. So I'll have to make the assistant run separate +git-annex processes for transfers, that can be individually sent signals. diff --git a/doc/design/assistant/blog/day_57__afk.mdwn b/doc/design/assistant/blog/day_57__afk.mdwn new file mode 100644 index 000000000..c72849ce7 --- /dev/null +++ b/doc/design/assistant/blog/day_57__afk.mdwn @@ -0,0 +1,40 @@ +Probably won't be doing any big coding on the git-annex assistant in the +upcoming week, as I'll be traveling and/or slightly ill enough that I can't +fully get into <a href="http://en.wikipedia.org/wiki/Flow_(psychology)">flow</a>. + +--- + +There was a new Yesod release this week, which required minor changes to +make the webapp build with it. I managed to keep the old version of Yesod +also supported, and plan to keep that working so it can be built with the +version of Yesod available in, eg, Linux distributions. TBD how much pain +that will involve going forward. + +--- + +I'm mulling over how to support stopping/pausing transfers. The problem +is that if the assistant is running a transfer in one thread, and the +webapp is used to cancel it, killing that thread won't necessarily stop the +transfer, because, at least in Haskell's thread model, killing a thread +does not kill processes started by the thread (like rsync). + +So one option is to have the transfer thread run a separate git-annex +process, which will run the actual transfer. And killing that process will +stop the transfer nicely. However, using a separate git-annex process means +a little startup overhead for each file transferred (I don't know if it'd +be enough to matter). Also, there's the problem that git-annex is sometimes +not installed in PATH (wish I understood why cabal does that), which +makes it kind of hard for it to run itself. (It can't simply fork, sadly. +See past horrible pain with forking and threads.) + +The other option is to change the API for git-annex remotes, so that +their `storeKey` and `retrieveKeyFile` methods return a pid of the program +that they run. When they *do* run a program.. not all remotes do. This +seems like it'd make the code in the remotes hairier, and it is also asking +for bugs, when a remote's implementation changes. Or I could go +lower-level, and make every place in the utility libraries that forks a +process record its pid in a per-thread MVar. Still seems to be asking for +bugs. + +Oh well, at least git-annex is already crash-safe, so once I figure out +how to kill a transfer process, I can kill it safely. :) diff --git a/doc/design/assistant/blog/day_57__afk/comment_1_70e1c9f925f040c1700d3e26bab373d5._comment b/doc/design/assistant/blog/day_57__afk/comment_1_70e1c9f925f040c1700d3e26bab373d5._comment new file mode 100644 index 000000000..c83403620 --- /dev/null +++ b/doc/design/assistant/blog/day_57__afk/comment_1_70e1c9f925f040c1700d3e26bab373d5._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="http://claimid.com/strager" + nickname="strager" + subject="comment 1" + date="2012-08-11T04:50:52Z" + content=""" +What if `storeKey`, `retrieveKeyFile`, etc. return an `IO ()` which cancels the operation, if possible? The implementation can be canceled regardless if it uses separate processes or Haskell threads. + +"""]] diff --git a/doc/design/assistant/blog/day_57__afk/comment_2_c70d3faccfcebf47deb25e270498cb56._comment b/doc/design/assistant/blog/day_57__afk/comment_2_c70d3faccfcebf47deb25e270498cb56._comment new file mode 100644 index 000000000..7539ea2de --- /dev/null +++ b/doc/design/assistant/blog/day_57__afk/comment_2_c70d3faccfcebf47deb25e270498cb56._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="http://claimid.com/strager" + nickname="strager" + subject="comment 2" + date="2012-08-11T04:55:13Z" + content=""" +In fact, making a dedicated data type or some typeclasses may be more appropriate: + + class Cancelable a where cancel :: a -> IO () + class Pauseable a where pause :: a -> IO () + + -- Alternatively: + + data Transfer = Transfer { cancel :: IO (), pause :: IO () } + + -- Or both! + +"""]] diff --git a/doc/design/assistant/blog/day_57__afk/comment_3_89020ebc6d31485339bdea41a872df3c._comment b/doc/design/assistant/blog/day_57__afk/comment_3_89020ebc6d31485339bdea41a872df3c._comment new file mode 100644 index 000000000..ed02b9dce --- /dev/null +++ b/doc/design/assistant/blog/day_57__afk/comment_3_89020ebc6d31485339bdea41a872df3c._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + subject="comment 3" + date="2012-08-11T14:41:51Z" + content=""" +That's the lines I was thinking along, and I even made a throwaway branch with some types. But the problem is reworking all the code to do that. Particularly since lots of the code uses generic utility functions that are reused in other, unrelated places and would have to be modified to pass back cancel actions. + +The first case the type checker landed me on when I changed the types was code that downloads an url from the web. Naturally that uses a Utility.Url.download. How to cancel `download`? Depends on its implementation -- it happens to currently shell out to curl, so you have to kill curl, but it could just as easily have used libcurl (other parts of my Utility.Url library do), and then it would need to fork its own thread. So it's an abstraction layer violation problem. + +If I had a month to devote to this one problem, I might manage to come up with some clean solution involving monads, or maybe convert all my code to use conduit or something that might allow managing these effects better. Just a guess.. +"""]] diff --git a/doc/design/assistant/blog/day_57__afk/comment_4_8b1f65f141ffd9813e7f5a3380f7f520._comment b/doc/design/assistant/blog/day_57__afk/comment_4_8b1f65f141ffd9813e7f5a3380f7f520._comment new file mode 100644 index 000000000..c87e447d1 --- /dev/null +++ b/doc/design/assistant/blog/day_57__afk/comment_4_8b1f65f141ffd9813e7f5a3380f7f520._comment @@ -0,0 +1,27 @@ +[[!comment format=mdwn + username="http://claimid.com/strager" + ip="173.228.13.253" + subject="comment 4" + date="2012-08-11T16:08:47Z" + content=""" +> How to cancel download? Depends on its implementation .... So it's an abstraction layer violation problem. + +Precisely why I suggested returning something as generic as `IO ()`: + + -- Current + download :: URLString -> Headers -> [CommandParam] -> FilePath -> IO Bool + + -- Suggestion + data Transfer a = Transfer { run :: IO a, cancel :: IO () } + download :: URLString -> Headers -> [CommandParam] -> FilePath -> Transfer + + transfer <- download ... + -- You can pass `cancel transfer` to another thread + -- which you want to be able to cancel the transfer. + run transfer -- blocking + +I realized while writing this that you may not get any result from e.g. a download while it is occurring (because the function is blocking). Maybe that's where a misunderstanding occurred. I separated the concepts of creating a transfer and starting/canceling it. + +(My idea is starting to feel a bit object-oriented... ;P) + +"""]] diff --git a/doc/design/assistant/blog/day_58__more_transfer_control.mdwn b/doc/design/assistant/blog/day_58__more_transfer_control.mdwn new file mode 100644 index 000000000..08b69a75d --- /dev/null +++ b/doc/design/assistant/blog/day_58__more_transfer_control.mdwn @@ -0,0 +1,26 @@ +Unexpectedly managed a mostly productive day today. + +Went ahead with making the assistant run separate `git-annex` processes for +transfers. This will currently fail if git-annex is not installed in PATH. +(Deferred dealing with that.) + +To stop a transfer, the webapp needs to signal not just the git-annex +process, but all its children. I'm using process groups for this, which is +working, but I'm not extremely happy with. + +Anyway, the webapp's UI can now be used for stopping transfers, and it +wasn't far from there to also implementing pausing of transfers. + +Pausing a transfer is actually the same as stopping it, except a special +signal is sent to the transfer control thread, which keeps running, despite +the git-annex process having been killed, waits for a special resume +signal, and restarts the transfer. This way a paused transfer continues to +occupy a transfer slot, which prevents other queued transfers from running. +This seems to be the behavior that makes sense. + +Still need to wire up the webapp's button for starting a transfer. For a +paused transfer, that will just need to resume it. I have not decided what +the button should do when used on a transfer that is queued but not running +yet. Maybe it forces it to run even if all transfer slots are already in +use? Maybe it stops one of the currently running transfers to free up a +slot? diff --git a/doc/design/assistant/cloud.mdwn b/doc/design/assistant/cloud.mdwn index bec3bc36b..1824a74ec 100644 --- a/doc/design/assistant/cloud.mdwn +++ b/doc/design/assistant/cloud.mdwn @@ -34,7 +34,7 @@ Also needed for USB keys and Android gadgets. Of course, one option is to just use github etc to store the git repo. -Two things can store git repos in Anazon S3: +Two things can store git repos in Amazon S3: * <http://gabrito.com/post/storing-git-repositories-in-amazon-s3-for-high-availability> * <http://wiki.cs.pdx.edu/oss2009/index/projects/gits3.html> diff --git a/doc/design/assistant/comment_11_a38f0f21c2346e65b786d791b6829f9b._comment b/doc/design/assistant/comment_11_a38f0f21c2346e65b786d791b6829f9b._comment new file mode 100644 index 000000000..71a9f155d --- /dev/null +++ b/doc/design/assistant/comment_11_a38f0f21c2346e65b786d791b6829f9b._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawneJXwhacIb0YvvdYFxhlNVpz6Wpg6V7AA" + nickname="Shayne" + subject="comment 11" + date="2012-08-13T00:37:35Z" + content=""" +Yeah definately go with homebrew rather than macports if possible. macports and fink, whilst great systems, have a tendency to sort of create their own alternative-dimension of files within the system that just dont always feel particularly well integrated. As a result \"brew\" has become increasingly more popular to the point its almost ubuquitous now. + +Plus its brew-doctor thing is awesome. + +The best approach though thats agnostic to distro systems is to simply go for a generic installer. +"""]] diff --git a/doc/design/assistant/inotify.mdwn b/doc/design/assistant/inotify.mdwn index fd81366d4..cb9bd0edc 100644 --- a/doc/design/assistant/inotify.mdwn +++ b/doc/design/assistant/inotify.mdwn @@ -28,6 +28,10 @@ available! * honor .gitignore, not adding files it excludes (difficult, probably needs my own .gitignore parser to avoid excessive running of git commands to check for ignored files) +* There needs to be a way for a new version of git-annex, when installed, + to restart any running watch or assistant daemons. Or for the daemons + to somehow detect it's been upgraded and restart themselves. Needed + to allow for imcompatable changes and, I suppose, for security upgrades.. ## beyond Linux diff --git a/doc/design/encryption/comment_5_520e60aa53217b5ba428d4c05d897dee._comment b/doc/design/encryption/comment_5_520e60aa53217b5ba428d4c05d897dee._comment new file mode 100644 index 000000000..ff579f49b --- /dev/null +++ b/doc/design/encryption/comment_5_520e60aa53217b5ba428d4c05d897dee._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkS6aFVrEwOrDuQBTMXxtGHtueA69NS_jo" + nickname="Hans" + subject="using sshfs + cryptmount is more secure" + date="2012-08-14T13:41:47Z" + content=""" +\"For git-annex, note that an attacker with local machine access can tell at least all the filenames and metadata of files stored in the encrypted remote anyway, and can access whatever content is stored locally.\" + +Better security is given by sshfs + cryptmount, which I used when I recently setup a git-annex repository on a free shell account from a provider I do not trust. + +See http://code.cjb.net/free-secure-online-backup.html for what I did to get a really secure solution. + +Kind regards, + +Hans Ekbrand +"""]] diff --git a/doc/design/encryption/comment_6_d677fead0fe0c543f48f07d85f83f592._comment b/doc/design/encryption/comment_6_d677fead0fe0c543f48f07d85f83f592._comment new file mode 100644 index 000000000..a2c7013fb --- /dev/null +++ b/doc/design/encryption/comment_6_d677fead0fe0c543f48f07d85f83f592._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo" + nickname="Justin" + subject="comment 6" + date="2012-08-14T14:10:40Z" + content=""" +Hans, + +You are misunderstanding how git-annex encryption works. The \"untrusted host\" and the \"local machine\" are not the same machine. git-annex only transfers pre-encrypted files to the \"untrusted host\". + +You should setup a git-annex encrypted remote and watch how it works so you can see for yourself that it is not insecure. + +Your solution does not provide better security, it accomplishes the same thing as git-annex in a more complicated way. In addition, since you are mounting the image from the client your solution will not work with multiple clients. +"""]] diff --git a/doc/design/encryption/comment_7_c1c38a09b1276e29adc3ba564dc0fe4e._comment b/doc/design/encryption/comment_7_c1c38a09b1276e29adc3ba564dc0fe4e._comment new file mode 100644 index 000000000..259214495 --- /dev/null +++ b/doc/design/encryption/comment_7_c1c38a09b1276e29adc3ba564dc0fe4e._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkS6aFVrEwOrDuQBTMXxtGHtueA69NS_jo" + nickname="Hans" + subject="comment 7" + date="2012-08-15T19:16:10Z" + content=""" +Justin, + +thanks for clearing that up. It's great that git-annex has implemented mechanisms to work securely on untrusted hosts. My solution is thus only interesting for files that are impractical to manage with git-annex (e.g. data for/from applications that need rw-access to a large number of files). And, possibly, for providers that do not provide rsync. + +Your remark that my solution does not work with more than one client, is not entirely accurate. No more than one client can access the repository at any given time, but as long as access is not simultaneous, any number of clients can access the repository. Still, your point is taken, it's a limitation I should mention. + +It would be interesting to compare the performance of individually encrypted files to encrypted image-file. My intuition says that encrypted image-file should be faster, but that's just a guess. +"""]] diff --git a/doc/download/comment_1_ec2578241a966cfcdd43f2a26a5c8709._comment b/doc/download/comment_1_ec2578241a966cfcdd43f2a26a5c8709._comment new file mode 100644 index 000000000..e242230a0 --- /dev/null +++ b/doc/download/comment_1_ec2578241a966cfcdd43f2a26a5c8709._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawm3uJkdiJJejvqix9dULvw_Ma7DCtB-6zA" + nickname="Ian" + subject="git clone git://git-annex.branchable.com/ gives an error" + date="2012-08-13T20:57:34Z" + content=""" +Thought you would want to know + +error: unable to create file doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2_however_syb-0.1.0.2_was_excluded_because_json-0.5_requires_syb___62____61__0.3.3.mdwn (File name too long) +fatal: cannot create directory at 'doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2_however_syb-0.1.0.2_was_excluded_because_json-0.5_requires_syb___62____61__0.3.3': File name too long + + +"""]] diff --git a/doc/download/comment_2_ee0d158ac59903737dbc4ef632f11fe3._comment b/doc/download/comment_2_ee0d158ac59903737dbc4ef632f11fe3._comment new file mode 100644 index 000000000..d3024217a --- /dev/null +++ b/doc/download/comment_2_ee0d158ac59903737dbc4ef632f11fe3._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + subject="comment 2" + date="2012-08-16T23:28:30Z" + content=""" +Ok, I've renamed that long-ish filename. +"""]] diff --git a/doc/forum/Delete_unused_files__47__metadata/comment_1_3efc19895c8dec89b71ae3778b583fea._comment b/doc/forum/Delete_unused_files__47__metadata/comment_1_3efc19895c8dec89b71ae3778b583fea._comment new file mode 100644 index 000000000..c0d779abd --- /dev/null +++ b/doc/forum/Delete_unused_files__47__metadata/comment_1_3efc19895c8dec89b71ae3778b583fea._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + subject="comment 1" + date="2012-08-07T20:06:26Z" + content=""" +You must have quite a number of files and/or location tracking churn to get the branch that large. + +Removing location tracking files for vanished files from the git-annex branch would not save much space.. Only a very little bit of tree object size going forward. The way the git-annex branch is merged does not really allow deleting files from it. And of course git uses space for even deleted files. + +It'd be possible to delete the git-annex branch entirely, first backing up git-annex:uuid.log git-annex:remote.log and git-annex:trust.log and then making a new, clean branch that those files are added back to. Then run git annex fsck on every clone to repopulate the location tracking info for files that still exit. (Note that this would also lose urls stored by `git-annex addurl`.) +"""]] diff --git a/doc/forum/Delete_unused_files__47__metadata/comment_2_23597d9468347b3d94257f3c02afe1b8._comment b/doc/forum/Delete_unused_files__47__metadata/comment_2_23597d9468347b3d94257f3c02afe1b8._comment new file mode 100644 index 000000000..340debc11 --- /dev/null +++ b/doc/forum/Delete_unused_files__47__metadata/comment_2_23597d9468347b3d94257f3c02afe1b8._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus" + nickname="Jimmy" + subject="comment 2" + date="2012-08-08T14:54:42Z" + content=""" +I'm sort of getting into the same issue as I run 'git-annex get .' and 'git annex sync' with one of the annexes that I have on a nightly basis to collect data for back up reasons. But it's good to know there is a work around for it. +"""]] diff --git a/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_4_183dd1c29f66539193e7c0b73f329430._comment b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_4_183dd1c29f66539193e7c0b73f329430._comment new file mode 100644 index 000000000..6ab9ebb25 --- /dev/null +++ b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_4_183dd1c29f66539193e7c0b73f329430._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + subject="comment 4" + date="2012-08-07T17:53:35Z" + content=""" +I recently encountered this problem on OSX, and I'm pretty sure I fixed it. But I don't remember the details of how. I'm sorry I don't have more detail, but I recommend trying a newer version of git-annex. + +And if the problem persists, --debug will show the git commands and should help identify the one that's being passed bad parameters. +"""]] diff --git a/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_5_c920d04ffe332caed9d223fa0ac42746._comment b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_5_c920d04ffe332caed9d223fa0ac42746._comment new file mode 100644 index 000000000..32420ac66 --- /dev/null +++ b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_5_c920d04ffe332caed9d223fa0ac42746._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + subject="remember now" + date="2012-08-07T19:37:22Z" + content=""" +This was a bug in determining the git version at compile time. Fixed in commit bafc50e05e098234d2d22886085d9844fc763e0e which was included in version 3.20120721. +"""]] diff --git a/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_6_7a3cf0853a8ec7b996e19b5e80145d21._comment b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_6_7a3cf0853a8ec7b996e19b5e80145d21._comment new file mode 100644 index 000000000..9ffb376a7 --- /dev/null +++ b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_6_7a3cf0853a8ec7b996e19b5e80145d21._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="hannes" + ip="130.226.133.37" + subject="awesome, thanks" + date="2012-08-08T12:25:19Z" + content=""" +works with an updated git-annex! +"""]] diff --git a/doc/special_remotes/S3.mdwn b/doc/special_remotes/S3.mdwn index 195693b3b..333e0bac5 100644 --- a/doc/special_remotes/S3.mdwn +++ b/doc/special_remotes/S3.mdwn @@ -36,5 +36,11 @@ the S3 remote. so by default, a bucket name is chosen based on the remote name and UUID. This can be specified to pick a bucket name. +* `fileprefix` - By default, git-annex places files in a tree rooted at the + top of the S3 bucket. When this is set, it's prefixed to the filenames + used. For example, you could set it to "foo/" in one special remote, + and to "bar/" in another special remote, and both special remotes could + then use the same bucket. + * `x-amz-*` are passed through as http headers when storing keys in S3. diff --git a/doc/special_remotes/S3/comment_4_38c0b062997fde1ad28facc05d973e83._comment b/doc/special_remotes/S3/comment_4_38c0b062997fde1ad28facc05d973e83._comment new file mode 100644 index 000000000..8c17f7d64 --- /dev/null +++ b/doc/special_remotes/S3/comment_4_38c0b062997fde1ad28facc05d973e83._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmX5gPNK35Dub-HzR0Yb3KXllbqc0rYRYs" + nickname="Eduardo" + subject="bucket/folder s3 remotes" + date="2012-08-09T10:52:07Z" + content=""" +it'd be really nice being able to configure a S3 remote of the form `<bucket>/<folder>` (not really a folder, of course, just the usual prefix trick used to simulate folders at S3). The remote = bucket architecture is not scalable at all, in terms of number of repositories. + +how hard would it be to support this? + +thanks, this is the only thing that's holding us back from using git-annex, nice tool! +"""]] diff --git a/doc/special_remotes/S3/comment_5_409bc2b56382417cf26bb222fb783ba7._comment b/doc/special_remotes/S3/comment_5_409bc2b56382417cf26bb222fb783ba7._comment new file mode 100644 index 000000000..325db6799 --- /dev/null +++ b/doc/special_remotes/S3/comment_5_409bc2b56382417cf26bb222fb783ba7._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + subject="comment 5" + date="2012-08-09T18:01:06Z" + content=""" +I guess this could be useful if you have a *lot* of buckets already in use at S3, or if you want to be able to have a lot of distinct S3 special remotes. Implemented the `fileprefix` setting. Note that I have not tested it, beyond checking it builds, since I let my S3 account expire. Your testing would be appreciated. + +"""]] diff --git a/doc/tips/using_gitolite_with_git-annex.mdwn b/doc/tips/using_gitolite_with_git-annex.mdwn index 0d89a255b..301e4a063 100644 --- a/doc/tips/using_gitolite_with_git-annex.mdwn +++ b/doc/tips/using_gitolite_with_git-annex.mdwn @@ -3,6 +3,8 @@ manager. Here's how to add git-annex support to gitolite, so you can `git annex copy` files to a gitolite repository, and `git annex get` files from it. +Warning : The method described here works with gitolite version g2, avaible in the g2 branch on github. There is an experimental support for g3 in the git-annex branch, if you tested it please add some feedback. + A nice feature of using gitolite with git-annex is that users can be given read-only access to a repository, and this allows them to `git annex get` file contents, but not change anything. @@ -30,13 +32,11 @@ Make the ADC directory, and a "ua" subdirectory. mkdir -p /usr/local/lib/gitolite/adc/ua </pre> -Install the git-annex-shell ADC into the "ua" subdirectory and make it -executable. +Install the git-annex-shell ADC into the "ua" subdirectory from the gitolie repository. <pre> cd /usr/local/lib/gitolite/adc/ua/ -wget https://raw.github.com/sitaramc/gitolite/pu/contrib/adc/git-annex-shell -chmod +x git-annex-shell +cp gitolite/contrib/adc/git-annex-shell . </pre> Now all gitolite repositories can be used with git-annex just as any diff --git a/doc/todo/windows_support/comment_4_ad06b98b2ddac866ffee334e41fee6a8._comment b/doc/todo/windows_support/comment_4_ad06b98b2ddac866ffee334e41fee6a8._comment new file mode 100644 index 000000000..66f9ca71f --- /dev/null +++ b/doc/todo/windows_support/comment_4_ad06b98b2ddac866ffee334e41fee6a8._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlc1og3PqIGudOMkFNrCCNg66vB7s-jLpc" + nickname="Paul" + subject="Re: What about NTFS support?" + date="2012-08-16T19:30:38Z" + content=""" +I successfully use git-annex on an NTFS formatted external USB drive, so yes, it is possible and works well. +"""]] |