analysis
authorJoey Hess <joeyh@joeyh.name>
Tue, 13 Dec 2016 14:40:50 +0000 (10:40 -0400)
committerJoey Hess <joeyh@joeyh.name>
Tue, 13 Dec 2016 14:46:24 +0000 (10:46 -0400)
doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run/comment_1_627bb742a5042741e9a1c294addd69b2._comment [new file with mode: 0644]

diff --git a/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run/comment_1_627bb742a5042741e9a1c294addd69b2._comment b/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run/comment_1_627bb742a5042741e9a1c294addd69b2._comment
new file mode 100644 (file)
index 0000000..8f84474
--- /dev/null
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-13T14:40:02Z"
+ content="""
+I thought this would involve the journal, but it seems not; same
+behavior occurs if the journal is committed after each metadata change.
+
+Looking at the new metadata value in the case where a and c both get set,
+it is:
+
+       MetaData (fromList [(MetaField "f",fromList [MetaValue (CurrentlySet True) "a",MetaValue (CurrentlySet False) "c"])])
+
+That is supposed to unset c, with the CurrentlySet False, but instead c
+remains set somehow.
+"""]]