On Fri, Aug 16, 2013 at 11:04 AM, Stephan Beal <sgb...@googlemail.com>wrote:
> On Fri, Aug 16, 2013 at 4:55 PM, Richard Hipp <d...@sqlite.org> wrote: > >> T +closed 6d42bcbef1a19fce44d20c43869399387b99a97b >>> T +closed abfc26f6da112a56821946ae9dff3fee8a0aa205 >>> U jan.nijtmans >>> >>> Therefore I propose to relax the restriction a little >>> such that this is allowed: T-cards should still be >>> in strict lexographical order, but the artifact-id's >>> should be taken into account first. >>> >> >> No. The correct fix is to put the T cards in the right order. >> > > Doesn't Jan's proposal make it possible to define the ordering in that > case? If only the card name or the +/-/*card name part is used, there can > be collisions (like the J-card case i pointed out earlier, but i'm happy > with restricting to unique J-card keys). Without extending the ordering to > include (as an ambiguity-buster) the uuid, it's not possible to put those > two closed tags in proper order - same key and same timestamp. > > It is important to keep the artifact format as simple as possible. And "cards are in lexicographical order" is much simpler than "the first two fields of cards are in lexicographical order except that if the first character of the second field of a J card is + or - or * then that character is elided and the comparison occurs on the remaining characters". The first rule is way simpler both in statement and in implementation. Now, if there were a compelling reason to go with the more complicated rule, we might consider it. But I can think of no good reason to have two J cards on the same field in the same artifact as they can be easily combined on client side before the artifact is created and there is no good reason to allow T cards to be out-of-order as they can be easily sorted by the client. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
