On 9/5/2013 2:41 PM, David Given wrote:
I think, without a mathematical proof, that maintaining the ability to
take prefixes of an encoded name will require us to use a dictionary
that fits into a precise number of bits. Truncating the dictionary to
2^10 entries would be the simplest approach, bu
On 9/5/2013 1:39 PM, Doug Franklin wrote:
These are going to get long, fast, as someone else already noted.
However, in the past I've seen algorithms to generate "random" "words"
that are still pronounceable, one character at a time. The trouble
here is likely to be the comparative lack of vowe
On 9/5/2013 4:54 PM, Matt Welland wrote:
The json timeline seems to have trouble with fossils fossil.
./configure --json && make
./fossil json timeline checkin --limit 100
Segmentation fault
On a lark, since I recently built fossil including json support, I
gave this a try. On my current projec
On Thu, Sep 5, 2013 at 7:43 PM, Ross Berteig wrote:
> One way to do that (again, blue sky, from someone not intimate with the
> insides of fossil) would be to cache the memorable names in a table where
> they can be located by SQL just as the prefix of a hash is now.
>
FWIW: that part is simple.
The json timeline seems to have trouble with fossils fossil.
./configure --json && make
./fossil json timeline checkin --limit 100
Segmentation fault
I ran into this in trying to write a script to tag all nodes with
-rNODENUM. An example where it works can be seen at:
http://chiselapp.com/user/k
On Thu, Sep 5, 2013 at 11:41 PM, David Given wrote:
> I don't think seven hex characters is unique enough, based on the stats
> other people have figured out. Could someone do the collision check on
> the NetBSD repository, if they have a copy? (It's not worth checking
> out, as it's kind of huge
On 05/09/13 15:21, David Given wrote:
> Richard Hipp wrote:
[...]
>> HHH -> WORD -> HH
>> HH ->WORD-WORD -> H
>> -> WORD-WORD-WORD ->
[...]
> I'll have a go tonight and see what happens --- the encoder/decoder is
> wrong and needs to be rewritten any
On 2013-09-05 13:43, Ross Berteig wrote:
First off, as you mentioned a few posts ago, you've got to get it
examining the bits in the same order and chunks regardless of the
"endianness" of the host. At that point, it seems like prefixing ought
to start working as expected.
I'm not convince
On Thu, Sep 5, 2013 at 11:52 AM, Matt Welland wrote:
> Can tickets be tagged? A quick browse of the tickets page and I conclude
> the answer is probably no. If tickets could be tagged similar to the
> timeline then tags could be used to give tickets a sync friendly short name
> which could be use
On Thu, Sep 5, 2013 at 10:39 PM, Doug Franklin
wrote:
> These are going to get long, fast, as someone else already noted. However,
> in the past I've seen algorithms to generate "random" "words" that are
> still pronounceable, one character at a time. The trouble here is likely
> to be the compar
The "fossil stash diff" command fails when used with the --tk option.
Bummer. It used to work
No time to fix it right now, as I'm actually using it on another project.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@l
On 9/5/2013 11:18 AM, Stephan Beal wrote:
i'm not 100% sure my query is right (i'm no SQL guru), but in the mail
fossil repo we seem to have only 14 collisions (across 21k blobs) at 6
digits:
So ran this query over my current project's repo, which has only 2254
blobs, for a range of pref
On 9/5/2013 6:55 AM, Richard Hipp wrote:
On Thu, Sep 5, 2013 at 6:27 AM, David Given mailto:d...@cowlark.com>> wrote:
playing with the encoder I see that:
12345678 = CRASH CHAPTER CASINO
123456 = ROVER TRIBAL EGO
1234 = JAMES ACTIVE
12 = ALCOHOL
I think the a
On Thu, Sep 5, 2013 at 5:52 PM, Matt Welland wrote:
> Can tickets be tagged? A quick browse of the tickets page and I conclude
> the answer is probably no. If tickets could be tagged similar to the
> timeline then tags could be used to give tickets a sync friendly short name
> which could be used
On 9/5/2013 3:27 AM, David Given wrote:
Out of interest, when do people using Fossil actually use hashes to
refer to things? It's fairly common to use the hash in git to refer to a
specific checkin, for example, but I've never found an urge to do that
in Fossil.
Personally I use them almost ent
On Thu, Sep 5, 2013 at 7:59 PM, Ross Berteig wrote:
> Mitigating the long hex problem for me is the fact that none of my
> projects have lasted long enough to grow to the point were using more than
> 4 to 6 digits of hash prefix feels dangerous.
>
i'm not 100% sure my query is right (i'm no SQL
Can tickets be tagged? A quick browse of the tickets page and I conclude
the answer is probably no. If tickets could be tagged similar to the
timeline then tags could be used to give tickets a sync friendly short name
which could be used in the ticket listings and when discussing the tickets.
The
Richard Hipp wrote:
[...]
> I think the above doesn't really work for an application like Fossil. I
> think that a prefix of the SHA1 hash should encode to a prefix of the
> mnemonic, and the other way arround too - a prefix of the mnemonic
> should decode back to a prefix of the original hash.
[.
On Thu, Sep 5, 2013 at 6:27 AM, David Given wrote:
> playing with the encoder I see that:
>
> 12345678 = CRASH CHAPTER CASINO
> 123456 = ROVER TRIBAL EGO
> 1234 = JAMES ACTIVE
> 12 = ALCOHOL
>
I think the above doesn't really work for an application like Fossil. I
think that a pref
On Thu, Sep 5, 2013 at 12:27 PM, David Given wrote:
> Out of interest, when do people using Fossil actually use hashes to
> refer to things? It's fairly common to use the hash in git to refer to a
> specific checkin, for example, but I've never found an urge to do that
> in Fossil.
>
i think we
Ross Berteig wrote:
> On 9/4/2013 2:40 PM, Stephan Beal wrote:
[...]
>> As before, i find it really cool, if even if only for its conversational
>> value. i can actually imagine that i'd use it (but won't really know
>> that until trying it out). i will certainly be forking this into
>> libfossil i
21 matches
Mail list logo
