On Wed, 21 Aug 2013 17:09:52 +0200, Richard Hipp <d...@sqlite.org> wrote:
On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson <m...@0branch.com> wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal <sgb...@googlemail.com>
wrote:
> DVCSs cannot, by their very nature, portably support sequential
numbers.
> This topic has been beaten to death by brains much larger than mine.
Joerg's original proposal (in a previous thread) was to support
_local_ sequential revision numbers as per Mercurial. That is, while
my revision 5 needn't match yours (e.g., autosync is off and we've
both committed), we can each still perform local operations using
these numbers (e.g., diff -r 3:5).
Please note that the internal record IDs are increasing, but not
sequential. In the self-hosting Fossil repository at www.fossil-scm.org,
the first check-in is 65, the second is 72, the third is 74, and fourth
is
85, and so forth. So even if the record IDs were exposed, they would not
give you sequential numbers as you get with mercurial.
I fully support Stephan's insistence on not exposing record IDs
unnecessarily.
It is, in theory, possible to support repository-specific sequential
version numbers, such as one finds in mercurial. This would require a
new
database table to maps the sequential numbers into record IDs and some
code
additions in various places to populate and use that new table. If you
think that having repository-specific sequential version numbers is a
good
thing (I do not) then you are welcomed to argue your case for that
enhancement. But, unfortunately, exposing record IDs is not quite the
same
thing.
thanks for this clarification. so, while you don't share my view that the
sequential revnums (yes: exactly the same thing as in mercurial) are a
good thing, I still do (from some years of usage of mercurial). I've tried
to argue for this in this thread and already some month ago in a different
one. I just can only reiterate:
-- locally there is no ambiguity/no problem
-- revnums are more human-friendly in different ways (notably for the
not-so-seldem diffs of successive revisions). something like
72:[3ac24d1cd2] 2013-01-11 j dresden tidy up.
71:[ced1483e1b] 2013-01-10 j dresden small fix.
70:[b7f21c3555] 2013-01-10 j dresden minor tidy up.
69:[34844683fd] 2013-01-10 j dresden small fix.
68:[b84e704411] 2013-01-10 j dresden bug fix (skipping of single word
remaini
67:[abc0e49ac5] 2013-01-10 j dresden tentative addition of chronological
revi
66:[4038632842] 2013-01-08 marc trunk Simplify the prompt regexp (no need
to e
65:[d183a47466] 2013-01-06 j dresden restore usual meaning of "line" in
`time
64:[de9dfa49ae] 2013-01-06 j dresden added new proc `reformTimeline' for
refo
63:[6c76c5ec8d] 2013-01-05 j dresden fixed comment sytnax bug.
62:[ba3a1b7d98] 2013-01-01 j dresden small fix.
61:[38deb932f7] 2013-01-01 j dresden merged from trunk.
as a timeline (or in this case: finfo -b) display plus support of this in
fossil allows to do, e.g.
fossil diff -r 69 --to 70 (and the convential `-r 69:70' syntax would
still be nicer) instead of fossil diff -r 3484 --to b7f2,
which might be seen as a minor convenience but looking up/copying/typing
the correct sha1 hashes is a continuous nuisance that never stops.
so the whole/sole point is a more comfortable CLI. in the mentioned script
at http://fossil.0branch.com/fsl/timeline?y=ci I did (in the dresden
branch) essentially what you propose as an additional map in the database:
go through the complete timeline and build an associative array whose keys
are the hashes and whose values are the numbers (and from that derive a
reverse one that allows to look up the hashes when the revnums are given).
the script than simply replaces the revnums by the hashes in the
constructed fossil call.
so I'm not sure what further arguments (that have not been stated
repeatedly) I could give ....
so if you could get around to implementing that map as a first step that
would be great (at least I could then avoid parsing the whole timeline
output to set up that map myself in the `fsl' script ;-)).
best,
j.
--
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
