Merge remote-tracking branch 'branchable/master'

5 files changed, 61 insertions, 0 deletions

diff --git a/doc/bugs/fat_support/comment_3_df3b943bc1081a8f3f7434ae0c8e061e._comment b/doc/bugs/fat_support/comment_3_df3b943bc1081a8f3f7434ae0c8e061e._comment
new file mode 100644
index 000000000..f3db75c2f
--- /dev/null
+++ b/doc/bugs/fat_support/comment_3_df3b943bc1081a8f3f7434ae0c8e061e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="fmarier"
+ subject="comment 3"
+ date="2011-04-05T10:00:21Z"
+ content="""
+Thanks for the reply @joey.
+
+While it would certainly be possible for a bare repo to exist on my iRiver, the problem is that the music player uses the filesystem to organize files into directories like \"Artist/Album/Track.ogg\". So replacing that with \"..../xx/yy/Track.ogg\" would make it fairly difficult to browse my music collection and select the album/track I want to listen to :)
+
+So unless I have the files physically organized like the symlinks, then it's probably not going to work very for that particular workflow. Smudge filters are interesting though. In the meantime, I'll look into rsyncing from another box which has the right filesystem layout onto my iRiver directly.
+"""]]
diff --git a/doc/design/encryption/comment_4_8f3ba3e504b058791fc6e6f9c38154cf._comment b/doc/design/encryption/comment_4_8f3ba3e504b058791fc6e6f9c38154cf._comment
new file mode 100644
index 000000000..14eb1acac
--- /dev/null
+++ b/doc/design/encryption/comment_4_8f3ba3e504b058791fc6e6f9c38154cf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2011-04-07T19:59:30Z"
+ content="""
+@Richard the easy way to deal with that scenario is to set up a remote that work can access, and only put in it files work should be able to see. Needing to specify which key a file should be encrypted to when putting it in a remote that supported multiple keys would add another level of complexity which that avoids.
+
+Of course, the right approach is probably to have a separate repository for work. If you don't trust it with seeing file contents, you probably also don't trust it with the contents of your git repository.
+"""]]
diff --git a/doc/forum/Problems_with_large_numbers_of_files/comment_6_4551274288383c9cc27cbf85b122d307._comment b/doc/forum/Problems_with_large_numbers_of_files/comment_6_4551274288383c9cc27cbf85b122d307._comment
new file mode 100644
index 000000000..fff8f7cdd
--- /dev/null
+++ b/doc/forum/Problems_with_large_numbers_of_files/comment_6_4551274288383c9cc27cbf85b122d307._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 6"
+ date="2011-04-07T18:09:13Z"
+ content="""
+I've committed the queue flush improvements, so it will buffer up to 10240 git actions, and then flush the queue.
+
+There may be other memory leaks at scale (besides the two I mentioned earlier), but this seems promising. I'm well into running `git annex add` on a half million files and it's using 18 mb ram and has flushed the queue several times. This run
+will fail due to running out of inodes for the log files, not due to memory. :)
+"""]]
diff --git a/doc/forum/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_3_2082f4d708a584a1403cc1d4d005fb56._comment b/doc/forum/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_3_2082f4d708a584a1403cc1d4d005fb56._comment
new file mode 100644
index 000000000..01dc7813f
--- /dev/null
+++ b/doc/forum/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_3_2082f4d708a584a1403cc1d4d005fb56._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2011-04-04T10:28:01Z"
+ content="""
+Going one step further, a --min-copy could put all files so that numcopies is satisfied. --all could push to all available ones.
+
+To take everything another step further, if it was possible to group remotes, one could act on the groups. \"all\" would be an obvious choice for a group that always exists, everything else would be set up by the user.
+"""]]
diff --git a/doc/forum/wishlist:_git_annex_status.mdwn b/doc/forum/wishlist:_git_annex_status.mdwn
new file mode 100644
index 000000000..add865410
--- /dev/null
+++ b/doc/forum/wishlist:_git_annex_status.mdwn
@@ -0,0 +1,19 @@
+Ideally, it would look similar to this. And yes, I put "put" in there ;)
+
+    non-annex % git annex status
+    git annex status: error: not a git annex repository
+    annex % git annex status
+    annex object storage version: A
+    annex backend engine: {WORM,SHA512,...}
+    Estimated local annex size: B MiB
+    Estimated total annex size: C MiB
+    Files without file size information in local annex: D
+    Files without file size information in total annex: E
+    Last fsck: datetime
+    Last git pull: datetime - $annex_name
+    Last git push: datetime - $annex_name
+    Last git annex get: datetime - $annex_name
+    Last git annex put: datetime - $annex_name
+    annex %
+
+Datetime could be ISO's YYYY-MM-DDThh:mm:ss or, personal preference, YYYY-MM-DD--hh-mm-ss. I prefer the latter as it's DNS-, tag- and filename-safe which is why I am using it for everything. In a perfect world, ISO would standardize YYYY-MM-DD-T-hh-mm-ss-Z[-SSSSSSSS][--$timezone], but meh.