unintentionally replied only to stephan, but this should stay on th list,
I'd say, so:
On Wed, 21 Aug 2013 16:08:16 +0200, Stephan Beal <sgb...@googlemail.com>
wrote:
On Wed, Aug 21, 2013 at 3:25 PM, j. van den hoff
<veedeeh...@googlemail.com>wrote:
"philosophical" issues aside:
does that mean that with the current implementation (and probably
"forever") the record
IDs are actually simply enumerating checkins (or everything (wiki,
tickets, etc.)?).
Yes, but don't get the idea that...
because if they are, I'd come back to an old wish of mine, namely to
make
these numbers visible in the
timeline output (at least on the command line) and to accept them
(probably with priority over SHA1 spec.)
instead of the hashes in all commands requiring revision
specification(s).
... they are guaranteed to be stable. The IDs are doled out by the db
system and it is not required to make them sequential. If record number N
is deleted, the db engine is (AFAIK) free to re-allocate that record ID
later. The external APIs/users should _never_ rely on these numbers.
(designed by marc simpson) does this already to some extent (in the
`dresden' branch only), i.e. displays
timeline entries with added chronological revision numbers (checkins
only)
derived from simply counting all entries in the
complete timeline and makes these numbers understood by `diff' ,`merge',
`up'. that's what I use
right now, but having the rev. numbers provided by fossil itself would
be
really appreciated.
The "rid" (record id) values "could" be used in such a way, but they are
an
implementation detail which i personally would not like to see
used/leaked
in client code. Any such use would be taking advantage of details which
could change tomorrow (i LIKE to change undefined behaviours just to
ensure
that no client code relies on them).
with due respect, that's too dogmatic for my taste. and it's also a
question what you decide to include
into the specification and what not, right? I understand that there is no
_need_
to enforce that the RIDs are sequential
but there seems to be no need either to change the de facto behavior and
make non-sequential RIDs a reality. meaning I don't see why the current
behavior could not be declared "will not change with 1.x releases" (or
never), so that one _could_ rely on it.
(NB: pleas don't explain again to me that these numbers are not
necessarily unique across clones -- I understand that -- and that they
are
thus EVIL (they are not) ;-))
i didn't say EVIL, i said UNRELIABLE, which is, in effect, much the same
thing. Unreliability is worse than no reliability.
so you did not say but _mean_ EVIL which is what matters and which is a
position I happen to not share (admittedly without knowing anything about
the inner workings of fossil):
after all, end-user experience ultimately decides about
success/dissemination of any software I would say and providing (AFAICS
without any adverse side effects) the end user with the ability to do
fossil `diff -r 123 --to 124' instead of `diff -r {unmemorizable sha1 code
goes here} --too {unmemorizable sha1 code goes here}' to get a diff
between successive checkins, e.g., would improve usability on the command
line w/o question.
if it is not going to happen, since nobody is willing (or has the time
resources) to do it, that's a pity in my view, but as so often a valid
decision on the side of the developers. arguing against the principal
desirability is another matter and here I really disagree.
and yes, one can work around this with scripts (that's why I'm happy that
marc simpson provided his `fsl' in the first place), but the very
existence of workarounds tells something about the existing CLI, namely
that shortcomings are of a degree that people really go to the trouble of
writing not-quite trivial scripts (something I have never observed with
`hg' and `svn'). nothing of this deters me from using fossil but still...
best
joerg
--
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
