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. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
