On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein
wrote:
> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
> veedeeh...@googlemail.com> wrote:
>
>> in a breach of promise to myself to never again argue in favour of this
>> functionality on the fossil mailing list (it came up a few times over th
The latest Fuel 2.0 is also quite usable now.
https://fuel-scm.org/fossil/home
On 10 September 2015 at 05:03, paul wrote:
> On 09/09/15 20:12, j. van den hoff wrote:
>
>> On Wed, 09 Sep 2015 20:19:04 +0200, Ron W wrote:
>>
>> On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari
>>> wrote:
>>>
>>>
On 09/09/15 20:12, j. van den hoff wrote:
On Wed, 09 Sep 2015 20:19:04 +0200, Ron W wrote:
On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari
wrote:
Some DVCS, like hg, use both an hash and a sequential number.
As I recall (been a few years since I last used hg), the numbers were
"relative" to
On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff
wrote:
> in a breach of promise to myself to never again argue in favour of this
> functionality on the fossil mailing list (it came up a few times over the
> last years):
>
> having simple chronological checkin numbers as an alternative way of
> s
On Wed, 09 Sep 2015 20:19:04 +0200, Ron W wrote:
On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari
wrote:
Some DVCS, like hg, use both an hash and a sequential number.
As I recall (been a few years since I last used hg), the numbers were
"relative" to the output of hg's equivalent to "timelin
On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari wrote:
>
> Some DVCS, like hg, use both an hash and a sequential number.
As I recall (been a few years since I last used hg), the numbers were
"relative" to the output of hg's equivalent to "timeline".
Assuming I am remembering correctly, if Fossil h
On 9/9/15, Stephan Beal wrote:
> On Wed, Sep 9, 2015 at 1:24 PM, Richard Hipp wrote:
>>
>> https://www.fossil-scm.org/fossil/timeline?y=ci&showid
>
>
> But be warned that they are not incremented in steps of 1. Any and all blob
> data in to the db gets its own number, so commits are normally
On Wed, Sep 9, 2015 at 1:24 PM, Richard Hipp wrote:
> Fossil also uses both the SHA1 hash and a sequential number. But only
> the hash is guaranteed to be stable (unchanged over the life of the
> project) and the same across all clones of the repo. So only the hash
> is shown and used.
>
> You
On 9/9/15, Luca Ferrari wrote:
> On Wed, Sep 9, 2015 at 10:16 AM, Scott Doctor
> wrote:
>>
>> Why does Fossil use a hash for an entries identity instead of sequential
>> numbering? Seems simply using the rowid of the associated database table
>> would be more meaningful and practical than those l
On Wed, Sep 9, 2015 at 10:16 AM, Scott Doctor wrote:
>
> Why does Fossil use a hash for an entries identity instead of sequential
> numbering? Seems simply using the rowid of the associated database table
> would be more meaningful and practical than those long strings of arbitrary
> numbers.
>
S
On Wed, Sep 9, 2015 at 10:16 AM, Scott Doctor wrote:
>
> Why does Fossil use a hash for an entries identity instead of sequential
> numbering? Seems simply using the rowid of the associated database table
> would be more meaningful and practical than those long strings of arbitrary
> numbers.
A
Because it is distributed. If sequential numbering is used two
disconnected clients can happen to use the same number for different
artifacts.
Regards,
Stan
Stanislav Paskalev
On Wed, Sep 9, 2015 at 11:16 AM, Scott Doctor wrote:
>
> Why does Fossil use a hash for an entries identity instead of
Why does Fossil use a hash for an entries identity instead of sequential
numbering? Seems simply using the rowid of the associated database table
would be more meaningful and practical than those long strings of
arbitrary numbers.
--
Scott Doctor
sc...@scottdoctor.com
--
13 matches
Mail list logo
