On Thu, 10 Jan 2013 13:35:06 +0100, Stephan Beal <sgb...@googlemail.com>
wrote:
On Thu, Jan 10, 2013 at 12:56 PM, j. van den hoff
<veedeeh...@googlemail.com
wrote:
I would find it useful if `fossil info' (or `stat', `timeline', or a new
command) would provide a means/option to show the total number of
revisions
(by default or optional), more precisely, the number of "file commits"
(as
it is called in `fossil help timeline) in the repo. the information
should
be there in the database (or could be added?) and an additional line of
output in `fossil info' would then do the trick. (sure one could also
write
a script analyszing `fossil timeline -ci ...' output to derive this
information but this is not desirable for large repos in my view.)
i'll sign up for adding that - i would be able to do this on Sunday. i
would add it to the "status" command because we have that info in the
/stat
page already (and in "fossil json stat -full").
ps: while I'm at it: adding the relative revision numbers to the output
of
`fossil timeline -ci' _and_ making them acceptable as keys instead of
the
SHA1 hashes in the relevant commands (notably `diff') would be very
nice,
too, but probably require more substantial changes.
The DVCS model means that _relative_ (sequential) revision numbers are
rendered absolutely meaningless because multiple users can work offline
in
parallel (and their system clocks might not be properly synced, breaking
time-based ordering). The sequential numbering problem is, in effect,
impossible to solve in a DVCS.
I'm aware of this and that's why I wrote "relative" in the first place.
still, the numbers do make sense _locally_ as a very handy means of
denoting/selecting a revision. confusion _could_ arise if different people
talk about "revision 11" without being aware that this is no good and they
need to use the sha1 hash (but practically, this should not be an issue).
by the way, the idea is not mine anyway but stolen from mercurial which
does just that, namely reporting the time line with identifiers formatted
as {rel_rev_number}:SHA1 and both (the rel. rev. and the hash) are
accepted in `diff' and friends.
works like a charm and saves lots of typing (locally chronological rev.
nums are much easier to memorize (and to type...) than sha1 hashes).
so I still think this would be useful.
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
