On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal <sgb...@googlemail.com>
wrote:
On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein <bmburst...@gmail.com>
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
the
last years):
If I understand correctly, the way fossil is designed could cause the
numbers to change *even locally* upon a rebuild, or even just a sync.
This
would probably get confusing.
Correct. And if i'm not mistaken, if you rebuild with the --randomize
option then the order could get even weirder.
well, I'm only talking about the ordinal numbers chronologically
enumerating the timeline checkin(!) entries. this enumeration will not
change as a consequence of rebuild, right? it might change after a sync
against some remote repo if there are incoming checkins chronologically
interleaved with my own, sure, but so what? the relative numbers would be
just a (somewhat "volatile") convenience measure _locally_. and I agree
with another recent post that this would primarily concern the CLI. what I
mean: go ask some hg users when they last did use sha1 hashes for
specifying checkins in their interaction with hg (which supports both the
ordinals as well as the hashes for doing so) and how often the presence of
those numbers confused communication with other developers in their
project. I'm quite sure they _never_ specify sha1 hashes to denote
checkins in any small to medium-sized project below 10^4 checkins
(currently
this still includes fossil itself). not so sure about the "communication"
issue if users forget the potentially 'volatile' nature of the relative
enumeration, but this just can't possibly be a big issue ...
I therefore just maintain it would be "nice to have". it sure ain't a
killer feature, I admit ...
(@Joerg: i was trying to remember who it was who used to ask for this
feature ;)
I plead guilty ;-). and will now keep quite again regarding this issue ....
--
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
