last mail in these matters since it is in danger of deteriorating into
just another flame.
On Wed, 21 Aug 2013 16:36:58 +0200, Stephan Beal <sgb...@googlemail.com>
wrote:
On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff
<veedeeh...@googlemail.com>wrote:
with due respect, that's too dogmatic for my taste. and it's also a
question what you decide to include
Domagtic, it is. It is a fact of software development, in particular
long-lived software, that once an internal implementation detail is
exposed
to clients, it makes changing the detail later much harder without
upsetting people. The more internal details which can be hidden, the more
resistant end-users are to changes in internal behaviour. It's about
long-term maintainability, not about end-user convenience.
you are stating/constructing a non-existent principal conflict between
long-term maintainability and end-user convenience here
into the specification and what not. 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.
DVCSs cannot, by their very nature, portably support sequential numbers.
This topic has been beaten to death by brains much larger than mine.
which is not relevant, I'm only talking about my local clone and how to
interact with it.
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):
Then submit a patch :).
yes sure, or write my own DVCS. not _that_ realistic at it stands.
after all, end-user experience ultimately decides about
success/dissemination of any software I would say and providing
Becoming a dominant DVCS is not, as far as i'm aware, a project goal.
neither is staying a niche application with a sub-optimal CLI.
(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.
Then figure out how to do with a DVCS and tell us how. The RIDs are NOT
something "we" (the royal we, meaning software developers in general) do
not want to expose - they are implementation details and exposing them
leads, long term, to grief and suffering. Dogmatic? Absolutely. But it's
a
hard-earned fact of life software developers eventually learn to accept
and
account for.
you must be talking about different issues not about the possibility of
enumerating checkins in a way that the user can access this info.
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...
Give me an algorithm which works and does not expose app-internal details
to the end users/scripts and i will commit to implementing it.
I really think we have a principal mis-understanding: the only think I
would like to have is access to the _locally_ valid ordinal numbers
(chronological enumeration) of the checkins. there is no ambiguity here,
whatsoever. as far as I understand you, the current RIDs essentially are
just these numbers? in the next step it would be perfect if `fossil' would
support these numbers as alternative (possibly to be prioritized in case
of names clash (rev num 1234 vs. sha1 hash 1234xxx)) to the hashes in all
the commands requiring revision info.
that's all.
regards,
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
