On 3/24/2016 11:03 AM, David Vines wrote:
On 23/03/2016 21:38, Ross Berteig wrote:
.... 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?
First, I'd hope that the CLI and web could be consistent. That they
aren't seems like a bug, albeit probably a low priority bug.
That said, fossil has always used the UUID aka SHA1 hash of a thing as
its only true name. That seems true of notes too, so it kind of makes
sense that you can have two at the same time stamp, at least as long as
whatever the hash is of differs.
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.
The web GUI operates through links to the SHA1 hash of the note. That
eliminates any ambiguity. It also only displays the time stamp to the
minute, which would cause notes that only differ in seconds to appear at
the "same" time.
Perhaps the CLI should do more to expose the (friendly sized) SHA1 hash
of both tech notes and wiki pages and accept either a hash prefix or
page name or time stamp to identify an existing note or page.
If there's no ambiguity, then the page or timestamp should also just
work. If there is ambiguity, then it should do something reasonable
following the example of anywhere else ambiguity can be an issue...
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.
Clearly if the attachment is not a technote, then it's creation at a
particular time should not prevent the creation of a technote with that
time stamp. And vice-versa, what happens if you create a technote and
attach a file such that both events happen on the same second?
Whatever the answer, that is worth a test case of its own.
IMHO, something like this should just work:
$ T=`date "+%F %T"`
$ fossil create "Build Failed" build.stdout.txt -M text/plain -t $T
$ fossil attach build.stderr.txt -t $T
should just work even if both commands happen to execute in the same
second as `date`.
Similarly, attaching more than one file to a single note or page should
work too, especially when scripted. I'm not sure what sort of trouble is
implied by that claim...
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).
Fossil's internal printf() has a custom %S format string for hashes that
magically trims them to the correct length for display. (There's also
%!S which trims them longer for safer use in HTML link targets which
might get bookmarked outside of fossil's control.) Documented in
src/printf.c.
Many thanks for the work you've done running the tests and commenting!
Just trying to give something back in support of a great tool. I don't
see any obvious missing features in fossil itself that I want to stick
my neck out and implement, but there is always one more test case that
could be written, and one more document, and most importantly I know how
to do that with some confidence that the result will be helpful.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
