diff --git a/doc/forum/Can_I_remove_a_groupwanted_expression__63__.mdwn b/doc/forum/Can_I_remove_a_groupwanted_expression__63__.mdwn new file mode 100644 index 0000000000..cbf3f327a6 --- /dev/null +++ b/doc/forum/Can_I_remove_a_groupwanted_expression__63__.mdwn @@ -0,0 +1,7 @@ +I associated a groupwanted expression with a group I called "common", but I don't want it any more. Can I remove it, so the group doesn't have any groupwanted expression? + +I tried to remove it with `git annex groupwanted common ''`, but when I run `git annex vicfg`, I just end up with `groupwanted common =`. Similarly, if I run `git annex vicfg` and delete that line, it seems to have no effect. + +I'm assuming (but haven't verified) that means I won't be able to use `groupwanted` properly with repos that are in `common` and also in a group that has a real expression associated with it. + +How can I make it so `common` no longer has an associated expression? diff --git a/doc/forum/Can_I_remove_a_groupwanted_expression__63__/comment_2_23d18b52d87468ffadf0a3e04bf8052d._comment b/doc/forum/Can_I_remove_a_groupwanted_expression__63__/comment_2_23d18b52d87468ffadf0a3e04bf8052d._comment new file mode 100644 index 0000000000..c1c622e132 --- /dev/null +++ b/doc/forum/Can_I_remove_a_groupwanted_expression__63__/comment_2_23d18b52d87468ffadf0a3e04bf8052d._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="falsifian" + avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae" + subject="comment 2" + date="2020-09-12T15:30:05Z" + content=""" +Update: I've verified that the empty groupwanted expression indeed does indeed block the groupwanted expression from another group. So, other than making sure I never use the `common` group again, or some manual repository surgery, I'm not sure how to recover from this situation. +"""]] diff --git a/doc/forum/Setting_required_to___34__groupwanted__34___doesn__39__t_work__44___but_copying_the_groupwanted_expression_does..mdwn b/doc/forum/Setting_required_to___34__groupwanted__34___doesn__39__t_work__44___but_copying_the_groupwanted_expression_does..mdwn new file mode 100644 index 0000000000..c885ae7db1 --- /dev/null +++ b/doc/forum/Setting_required_to___34__groupwanted__34___doesn__39__t_work__44___but_copying_the_groupwanted_expression_does..mdwn @@ -0,0 +1,27 @@ +I'm trying to give all my repositories the same requirements by putting them in a group "`common_requirements`" with a `groupwanted` expression. However, it looks like the requirement is not actually being applied: + + $ git annex required . + groupwanted + $ git annex group . + common_requirements + $ git annex groupwanted common_requirements + include=dump/angel-openbsd/* and not copies=not_angel-openbsd:3 + $ git annex fsck --quiet + [no output] + +The `fsck` should be complaining that some files are not present. If I set the `required` expression directly instead of using `groupwanted`, I get the behaviour I expected: + + $ git annex fsck --quiet + ** Required content dump/angel-openbsd/2020-09-12T01:20:52Z_level_0/_.bzip2 is missing from these repositories: + 91c090a3-a8fc-4540-83ec-57493967c708 -- em [here] + ** Required content dump/angel-openbsd/2020-09-12T01:20:52Z_level_0/_home.bzip2 is missing from these repositories: + 91c090a3-a8fc-4540-83ec-57493967c708 -- em [here] + ... (some output omitted) + git-annex: fsck: 10 failed + +Any idea what could cause `git annex required groupwanted` to behave differently from just copying the groupwanted expression in this case? Note that the repo is not in any other groups (see output of `git annex group .` above). I tried to reproduce this with some fresh toy repositories but wasn't able to --- in my controlled setting, `git annex required groupwanted` did what I wanted. + +A couple notes about the context here: + +* `dump/angel-openbsd` contains dumps of my host "`angel-openbsd`", and I want them to be stored in at last two repos other than `angel-openbsd` (no point in storing backups on the same computer). This repo should really be in the `not_angel-openbsd` group but I took it out of that group to make sure the issue isn't multiple conflicting `groupwanted` expressions. +* I would really like to have a global "requirements" setting that generalizes `numcopies`. My `common_requirements` group is a hack to try to achieve this, but I think I will run into trouble if I want to actually use git-annex's `groupwanted` functionality for anything else. diff --git a/doc/forum/is_windows_really_slow__63__.mdwn b/doc/forum/is_windows_really_slow__63__.mdwn new file mode 100644 index 0000000000..18e74fb21e --- /dev/null +++ b/doc/forum/is_windows_really_slow__63__.mdwn @@ -0,0 +1,16 @@ +I am trying annex for the first time. +I am trying it on windows (installed the beta). +My understanding from reading the docs is that it uses the repo in fully unlocked mode because windows does not support symlinks (or so git / git-annex believes). + +I currently have about 55K files and 220GB... mostly pictures. + +I have sidecar XMP files (text) next to each jpeg. +When I git add the XMP files, it is very very slow (about 1s per file). +When I do git status after adding them it takes minutes (refreshing index...). + +I have a pretty powerful machine: +Processor Intel(R) Core(TM) i9-7940X CPU @ 3.10GHz, 3096 Mhz, 14 Core(s), 28 Logical Processor(s) +128GB RAM +2TB NVMe SSD (~3GB/s symmetric transfer rate). + +My gut feel is that it is because all the jpgs remain in the worktree as opposed to symlinked, but wanted to hear an expert opinion? diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_13_121ae7a2803975e3bdcb5f9df0c4af3f._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_13_121ae7a2803975e3bdcb5f9df0c4af3f._comment new file mode 100644 index 0000000000..b496f647ed --- /dev/null +++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_13_121ae7a2803975e3bdcb5f9df0c4af3f._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="updating the standalone distribution to 8.20200908" + date="2020-09-12T15:20:18Z" + content=""" +Building the standalone distribution on conda-forge doesn't seem possible, unfortunately, since the build environment there is CentOS not Debian. + +@joey, when you get a chance, could you update the [https://downloads.kitenet.net/git-annex/linux/current/](https://downloads.kitenet.net/git-annex/linux/current/) and [http://archive.org/download/git-annex-builds](http://archive.org/download/git-annex-builds) version to 8.20200908 ? [Current version there](http://archive.org/download/git-annex-builds/SHA256E-s55287727--50bd5f4673fe85859b0a2c1cc4b68c93ace4ba3fca1b4eeeedeb0f3f243b9bad.tar.gz) is 8.20200815 , which is not an official release. +Thanks! + +"""]] diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_14_5183f3d940ef116b07f88bac25cb97a8._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_14_5183f3d940ef116b07f88bac25cb97a8._comment new file mode 100644 index 0000000000..6a26d0f56a --- /dev/null +++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_14_5183f3d940ef116b07f88bac25cb97a8._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="standalone build version oddity" + date="2020-09-12T19:07:55Z" + content=""" +Oddly, the mtime of the files at [https://downloads.kitenet.net/git-annex/linux/current](https://downloads.kitenet.net/git-annex/linux/current) is 2020-09-08, which does correspond to the latest git-annex release; but when run, it prints \"git-annex version: 8.20200815-g6ea511beb\". +"""]]