On Tue, Apr 8, 2014 at 7:37 AM, Andy Bradford amb-fos...@bradfords.orgwrote:
As for breaking something that used to work (though not very well or
consistently), we could certainly put it to a vote.
AFAIR the point of collisions with Events has never been mentioned/pointed
out before. i,
On Mon, Apr 7, 2014 at 11:43 PM, Andy Goth andrew.m.g...@gmail.com wrote:
On 4/7/2014 8:59 PM, Andy Bradford wrote:
To be fair, there is still one type of UUID that will work at a
shorter length than 4; events currently do not go through collision
detection, so it's possible to view an event
Thus said Stephan Beal on Tue, 08 Apr 2014 16:58:00 +0200:
AFAIR the point of collisions with Events has never been
mentioned/pointed out before. i, for one, would be all for the UUID
resolution treating events equally, _but_ that opens up potential new
UUID ambiguities
On 4/6/2014 12:08 AM, Andy Bradford wrote:
Thanks for the collisions!
First time I was ever thanked for collisions.
http://fossil.bradfords.org:8080/info/6b8e
http://fossil.bradfords.org:8080/info/2898
Those look fine, but did you really intend to reject all requests for
UUID abbreviations
On Mon, Apr 7, 2014 at 9:33 PM, Andy Goth andrew.m.g...@gmail.com wrote:
Those look fine, but did you really intend to reject all requests for
UUID abbreviations shorter than four characters?
The internal routine which converts symbolic names to UUIDs requires a
minimum of 4 digits before it
Thus said Andy Goth on Mon, 07 Apr 2014 14:33:10 -0500:
Those look fine, but did you really intend to reject all requests for
UUID abbreviations shorter than four characters?
Yes, it was intentional. It was not my intention to change the length at
which short UUIDs were supported, only to
Thus said Andy Bradford on 07 Apr 2014 19:59:33 -0600:
It's possible that one of these will collide with a ticket, ticket
change or other blobs... Should these also be subject to the same
test?
By the way, in the event that there is a collision, the blob is
preferred over
On 4/7/2014 8:59 PM, Andy Bradford wrote:
Thus said Andy Goth on Mon, 07 Apr 2014 14:33:10 -0500:
Those look fine, but did you really intend to reject all requests
for UUID abbreviations shorter than four characters?
Yes, it was intentional. It was not my intention to change the length
at
Thus said Andy Goth on Mon, 07 Apr 2014 22:43:21 -0500:
I do prefer consistency, but we're going to need to think more about
whether we want to break something which used to work just for the
sake of consistency.
I'm leaning more towards the thought that this didn't really work well
Thus said Andy Goth on Thu, 03 Apr 2014 13:07:44 -0500:
Thus said Andy Goth on Wed, 02 Apr 2014 21:37:35 -0500:
When the UUID is abbreviated to one or two characters, the
ambiguous artifact page is bypassed, and it always seems to link to
a ticket.
On 4/3/2014 12:46 AM, Andy Bradford wrote:
Thus said Andy Goth on Wed, 02 Apr 2014 21:37:35 -0500:
When the UUID is abbreviated to one or two characters, the ambiguous
artifact page is bypassed, and it always seems to link to a ticket.
It appears that if you happen to have a ticket UUID/SHA1
When the UUID is abbreviated to three characters, no artifact is found.
When the UUID is abbreviated to one or two characters, the ambiguous
artifact page is bypassed, and it always seems to link to a ticket.
Good (shows two ticket changes):
http://www.fossil-scm.org/index.html/info/4e684
Thus said Andy Goth on Wed, 02 Apr 2014 21:37:35 -0500:
When the UUID is abbreviated to three characters, no artifact is
found.
When the UUID is abbreviated to one or two characters, the ambiguous
artifact page is bypassed, and it always seems to link to a ticket.
This explains part
Thus said Andy Goth on Wed, 02 Apr 2014 21:37:35 -0500:
When the UUID is abbreviated to one or two characters, the ambiguous
artifact page is bypassed, and it always seems to link to a ticket.
This explains why it always links to a ticket once you get to ``4e'' and
just ``4'' for the UUID:
14 matches
Mail list logo
