On 23/03/2016 21:38, Ross Berteig wrote:
With my 1.2 sec delay in place the first two entries are guaranteed to land on
distinct seconds and
the test succeeds. Without it, the first three or four events all land in the
same second and the
test case fails.
Hmm, well my thought was that the cli shouldn't allow technotes with duplicate timestamps, in which
case having the 1.2s delay is correct (to allow the test to create a new technote with a unique time
delay). However the web UI does allow the creation of technotes with identical timestamps, so I'm
not as sure that having the CLI prevent this is as correct as I first thought.
Any thoughts on that?
Of course, as implemented, when they are multiple technotes with the same timestamp, the fossil wiki
commit and fossil attachment commands end up picking different ones (attachment will pick the one
with most recent modification time, wiki commit picks whichever sqlite feels like picking when no
order is specified on the relevant select command) - so in any event that needs sorting out.
Additional testing shows that it is specifically the attachment added to an
older note that causes a
shadow of a new technote to be created. That shadow is visible to the fossil
wiki list --technote
command, but does not appear in the timeline as a technote.
Is this a bug in the fossil attach command? In the technote handling? In the
timeline? or in the
documentation?
I think it's a bug in the fossil wiki list --technote command - as with attachments to wiki pages
and tickets there's an event created to record the attachment, but these shouldn't appear on the
fossil wiki list --technote output as they are not edittable (i.e. conceptually they're not
technote's, just entries on the timeline). The code should also allow you to create technotes with
the same timestamp as one of these and pick the proper technote if you choose to edit it.
On a related note, it would appear that way too long a prefix for the SHA1
artifact ids is being
used for the Add attachment entries displayed by fossil timeline. I would
imagine that the same
prefix length for display of checkin ID would be suitable.
I'll look into that as well the other two issues identified in this post (inconsistent choice when
multiple technotes have the same timestamp; fossil wiki list --technote showing non technote events
in the listing).
Many thanks for the work you've done running the tests and commenting!
Dave
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
