On Wed, 11 Feb 2015 20:51:39 +0100, Ross Berteig <r...@cheshireeng.com>
wrote:
On 2/11/2015 6:23 AM, Richard Hipp wrote:
On 2/11/15, j. van den hoff <veedeeh...@googlemail.com> wrote:
whatever the reason, the netbsd example (a worst case scenario, really)
would suggest to chose 12 instead of 10 as the future default length
to avoid collisions these next some hundred years.
Maybe the default prefix lengths should auto-adjust depending on the
number of artifacts in the repository?
The ability to use just a hash prefix is a virtually necessary
convenience for command-line users who would otherwise be faced with the
need to type full hashes.
But why use HEX digits for this?
We could use a denser encoding: with base32 a 10 character prefix would
be 50 bits, more than the 48 bits of 12 characters of hex. A base32
representation using case independent letters and the digits could also
avoid the easily confused letters. Of course higher bases would increase
density and allow shorter prefixes by default.
There would also be an advantage in URLs that use the full hash. Base 64
would need about 27 characters to cover the full 160 bit hash instead of
the current 40 characters.
Adding a second representation (naturally you have to preserve support
for hex, if only to prevent confusion from external references to
existing artifacts) does add the twist of a possible collision between
representations. You could handle that by requiring that all non-hex
hashes begin with a non-hex digit.
I have no real opinion regarding your suggestion other than that it seems
an incremental
improvment regarding convenience, not a massive one. but the devs should
answer that one.
regarding your primary question 'But why use HEX digits for this?' I will
always maintain
that the solution for 95-99% of repositories/projects would be to just
provide and use
a chronological decimal enumeration of the checkins. `hg' (mercurial) has
always done this:
@ changeset: 1261:2f0ee1dcbbb8
|\ bookmark: master
| | tag: default/master
| | tag: tip
| | parent: 1259:59d3ec2c5c57
| | parent: 1260:0cb8c040d0cb
| | user: elextr <ele...@gmail.com>
| | date: Fri May 16 10:57:04 2014 +1000
| | summary: Merge pull request #29 from florentx/sys-exit
| |
| o changeset: 1260:0cb8c040d0cb
|/ user: Florent Xicluna <florent.xicl...@gmail.com>
| date: Thu May 15 18:14:12 2014 +0200
| summary: Use standard sys.exit() instead of the fragile exit from
site.py module
|
where you have an 'ascii-art' representation of the DAG beside the timeline
(if fossil acquires this facility for the CLI one day that would be great,
too!) and `hg'
understands, e.g., both 1261 (the auto-incrementing enumeration _and_
2f0ee1dcbbb8 (the
sha1 prefix (12 digits in this case)) as a reference to that checkin.
there were discussions about this by and then on the list and the bottom
line seems to
be the devs don't like the idea (among other reasons because of the fact
that the enumeration
in general is not unique across different clones of the same project --
which I find irrelevant
since we are talking about local CLI usage of the enumeration and not of
identifying
unambiguously the respective checkins in communications with other users
or similar. I also
never have heard of hg running into problems due to this) so we will not
see it in fossil, I think.
for that very reason I augmented the `fsl' script
(http://fossil.0branch.com/fsl/home) to emulate this behaviour and my
re-formatted "timeline" output now looks, e.g. like this:
2014-07-27 15:20:04 163:[54308f65b8] *CURRENT* this fixes previous
checkin. (user: j tags: dresden)
2014-07-27 15:14:39 162:[b803dbe208] make `fsl cat' understand revision
numbers specified at the end, too. (user: j tags: dresden)
2014-07-27 14:59:19 161:[25259267f0] make `cat' aware of chronological
revision numbers. some minor edits. (user: j tags: dresden)
and I can do, for instance, `fsl d -r 162 --to 163' instead of `fossil
diff -r b803 --to 5430' which is easier to type and easier
to remember, notably regarding diffs between a certain checkin and the
previous or following one. and accidental collisions are definitely
ruled out while you can get them rather easily with the minimum sha1
prefix of length 4.
for large projects the numeric indices start to loose their advantage
somewhat, for sure, but for many many "small" projects (including
fossil) such numbers are easier to use than anything else. being able to
use them as an alternative to specifying the hashes really is
convenient.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
