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.
> 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.
> 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 :).
> 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.
> (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.
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.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
