From 2505722d330bda91b6c940a57a36c0e7d6bf4b5d Mon Sep 17 00:00:00 2001 From: oliv5 Date: Wed, 25 Sep 2019 07:41:51 +0000 Subject: [PATCH 1/6] Added a comment --- ..._e524de262247edc4c541ce3af92c48e0._comment | 43 +++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 doc/bugs/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e524de262247edc4c541ce3af92c48e0._comment diff --git a/doc/bugs/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e524de262247edc4c541ce3af92c48e0._comment b/doc/bugs/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e524de262247edc4c541ce3af92c48e0._comment new file mode 100644 index 0000000000..f38adabb5a --- /dev/null +++ b/doc/bugs/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e524de262247edc4c541ce3af92c48e0._comment @@ -0,0 +1,43 @@ +[[!comment format=mdwn + username="oliv5" + avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b" + subject="comment 2" + date="2019-09-25T07:41:51Z" + content=""" +Sorry for the long answer delay. + +I tried the given commands, after fixing the \"insert\" one a little (syntax). + + $ sqlite3 /media/mydisk/tmp/db + SQLite version 3.27.2 2019-02-25 16:06:06 + Enter \".help\" for usage hints. + sqlite> create table foo (name varchar); + Error: database is locked + sqlite> .exit + + $ sqlite3 /tmp/db + SQLite version 3.27.2 2019-02-25 16:06:06 + Enter \".help\" for usage hints. + sqlite> create table foo (name varchar); + sqlite> insert into foo \"joey\"; + Error: near \"\"joey\"\": syntax error + sqlite> insert into foo (name) values (\"joey\") + sqlite> .exit + + $ ls -l /media/mydisk/tmp/db + -rw-rw---- 1 olivier users 0 sept. 25 2019 db + + $ ls -l /tmp/db + -rw-r--r-- 1 olivier olivier 12288 sept. 25 09:29 /tmp/db + + $ echo \"test\" > /media/mydisk/tmp/test + $ ls -l /media/mydisk/tmp/test + -rw-rw---- 1 olivier users 5 sept. 25 09:34 /media/wdtv/tmp/test + + $ id olivier + uid=1000(olivier) gid=1000(olivier) + groupes=1000(olivier),4(adm),8(mail),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),999(spi),998(i2c),997(gpio),114(lpadmin),1001(download) + +The diff between /tmp and /media/mydisk/tmp is the filesystem, /tmp being in RAM. It seems that sqlite does not like the user rights and owner of files mounted by CIFS, here \"olivier:users\", even though user \"olivier\" can read/write files there and belongs to group \"users\". + +"""]] From 763f36e14b2950ad917f5757eee3748b876d51f7 Mon Sep 17 00:00:00 2001 From: "https://christian.amsuess.com/chrysn" Date: Wed, 25 Sep 2019 14:01:02 +0000 Subject: [PATCH 2/6] wishlist for using v7 --- doc/forum/Preserving_the_v5_experience.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/forum/Preserving_the_v5_experience.mdwn diff --git a/doc/forum/Preserving_the_v5_experience.mdwn b/doc/forum/Preserving_the_v5_experience.mdwn new file mode 100644 index 0000000000..df928a10b2 --- /dev/null +++ b/doc/forum/Preserving_the_v5_experience.mdwn @@ -0,0 +1,14 @@ +The v5 version had a few advantages over the v7 version (at least when no direct mode was involved); in particular: + +1. Annexed and plain git files could be kept in parallel +2. Files that are under annex control are immediately recognized as such (in file managers by displaying a symlink icon) +3. Never is a file readable with its wrong content (an absent file reads as ENOTFOUND rather than "/annex/...") +4. Never do changes resulting from users' workflows (who checks out what where, who locks something) show up in the actual git history. + +I'd like to configure my annex repositories to give those properties, but that may need some more options: + +* Setting `* annex.largefiles=nothing` in `.gitattributes` restores 1 (and can still be customized) +* Customizing it or users locking files still leaves files in their v7locked state where they can be accidentally read or otherwise look like plain available files (2-4). Having a `annex.neverlock` option that plain-out rejects adding files in locked mode or locking them would keep history and file list clean. That should be a `git annex config` option. +* There could still be an `git annex adjust --locked` that gives users the option to have a locked adjust branch (or lock files in their own adjusted branch) without those changes propagating into every user's history. + +When `neverlock` is active and `git add` is run on a largefile, it could reject adding the file, place the users in a `--lock` adjusted branch, or add the file in a locked state. From fea6124f7581af442c834644c51798a5d774c194 Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Wed, 25 Sep 2019 15:26:39 +0000 Subject: [PATCH 3/6] Added a comment --- ...comment_1_9b188fecb7eaeb3ec3ba47f4c5e17e37._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/forum/Preserving_the_v5_experience/comment_1_9b188fecb7eaeb3ec3ba47f4c5e17e37._comment diff --git a/doc/forum/Preserving_the_v5_experience/comment_1_9b188fecb7eaeb3ec3ba47f4c5e17e37._comment b/doc/forum/Preserving_the_v5_experience/comment_1_9b188fecb7eaeb3ec3ba47f4c5e17e37._comment new file mode 100644 index 0000000000..733433c2b0 --- /dev/null +++ b/doc/forum/Preserving_the_v5_experience/comment_1_9b188fecb7eaeb3ec3ba47f4c5e17e37._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="comment 1" + date="2019-09-25T15:26:39Z" + content=""" +\"Having a annex.neverlock option that plain-out rejects adding files in locked mode\" -- did you mean unlocked mode? + +A related suggestion: [[todo/auto-lock_files_after_one_edit]] +"""]] From 1bd5a36c0f8b0483b718a07d06b8bace4971cec7 Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Wed, 25 Sep 2019 17:24:21 +0000 Subject: [PATCH 4/6] Added a comment --- ...comment_2_d2da6d56980b535431d7f0360f58d04c._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/forum/Preserving_the_v5_experience/comment_2_d2da6d56980b535431d7f0360f58d04c._comment diff --git a/doc/forum/Preserving_the_v5_experience/comment_2_d2da6d56980b535431d7f0360f58d04c._comment b/doc/forum/Preserving_the_v5_experience/comment_2_d2da6d56980b535431d7f0360f58d04c._comment new file mode 100644 index 0000000000..12f22c52b8 --- /dev/null +++ b/doc/forum/Preserving_the_v5_experience/comment_2_d2da6d56980b535431d7f0360f58d04c._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="comment 2" + date="2019-09-25T17:24:21Z" + content=""" +Related: [[forum/lets_discuss_git_add_behavior]] + +I agree that (1)-(4) were good properties. (4) could be mitigated by using `git commit --amend` to merge the lock/unlock change with the previous commit. But if the previous commit has been pushed to a shared repo, this could cause problems. Something like [[todo/auto-lock_files_after_one_edit]] would restore (1)-(4), at the cost of requiring manual unlock to edit again as in v5. +"""]] From f9aae586a8d5e6a43cc9d12ac7b370b09abea373 Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Wed, 25 Sep 2019 17:34:33 +0000 Subject: [PATCH 5/6] Added a comment --- ...comment_1_afc78ecd06f0ee9a70ea6c89a8b63e46._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/auto-lock_files_after_one_edit/comment_1_afc78ecd06f0ee9a70ea6c89a8b63e46._comment diff --git a/doc/todo/auto-lock_files_after_one_edit/comment_1_afc78ecd06f0ee9a70ea6c89a8b63e46._comment b/doc/todo/auto-lock_files_after_one_edit/comment_1_afc78ecd06f0ee9a70ea6c89a8b63e46._comment new file mode 100644 index 0000000000..4f2d451eff --- /dev/null +++ b/doc/todo/auto-lock_files_after_one_edit/comment_1_afc78ecd06f0ee9a70ea6c89a8b63e46._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="comment 1" + date="2019-09-25T17:34:33Z" + content=""" +Maybe also, an option to auto-unlock the file right after commit? E.g. based on `.gitattributes`. Basically, unlocked files would look locally modified to `git`, but if their contents hasn't changed, the modification would just look like `typechange` from symlink to blob. It can actually be useful to see all unlocked files this way. + +This of course negates the point of v7, but [[sometimes|forum/Preserving_the_v5_experience]] the v5 model is a better fit. +"""]] From fb8a121686a42dc2c87facdbd921502ba0cb329c Mon Sep 17 00:00:00 2001 From: "amindfv@6f75355c5dad3450ed73d1f01715be90dfdd6cd6" Date: Thu, 26 Sep 2019 15:19:12 +0000 Subject: [PATCH 6/6] Added a comment --- ..._1_e4b2199944c3a248562bddf3cf9e2829._comment | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/workflow/comment_1_e4b2199944c3a248562bddf3cf9e2829._comment diff --git a/doc/workflow/comment_1_e4b2199944c3a248562bddf3cf9e2829._comment b/doc/workflow/comment_1_e4b2199944c3a248562bddf3cf9e2829._comment new file mode 100644 index 0000000000..ff12c0eca4 --- /dev/null +++ b/doc/workflow/comment_1_e4b2199944c3a248562bddf3cf9e2829._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="amindfv@6f75355c5dad3450ed73d1f01715be90dfdd6cd6" + nickname="amindfv" + avatar="http://cdn.libravatar.org/avatar/9cdda587f634ea9a85b34b25be421676" + subject="comment 1" + date="2019-09-26T15:19:12Z" + content=""" +For workflow 6 (\"Manual management of git history without the synchronizer\"), how can files be synchronized across repositories? + +Do you still need the workflow of adding remotes and using `git annex get --from=`? + +Is it possible to do some variant of `git annex get --from=`? How about `git annex get --from=`? (And if so, side question: what's the best way to get a repo's UUID?) + +Is it possible to transfer files between repos without explicitly creating remotes? If so, how? Are there gotchas when moving files \"by hand\" like permissions to be set? + +Thanks! +"""]]