On 21 Aug 2013 23:22, "j. van den hoff" <veedeeh...@googlemail.com> wrote: > > On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen <mpc.jans...@gmail.com> wrote: > >> On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff >> <veedeeh...@googlemail.com>wrote: >> >>> On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen <mpc.jans...@gmail.com> >>> wrote: >>> >>> To make this less of an academic discussion and to just be able to play >>>> >>>> >>> >>> very good point (despite being myself in academia ...) and thanks a lot >>> for sharing this. >>> >>> >>> around with it, >>>> >>>> >>>> http://mpcjanssen.nl/fossil/**fossil/vdiff?from=root:** >>>> revlist&to=r:5746&sbs=1< http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:revlist&to=r:5746&sbs=1 >has >>>> >>>> an implementation of having repository local rev numbers for commits >>>> >>> >>> I my view revnums for checkins only is absolutely sufficient/just right. >>> >>> >>> only. >>>> >>>> After updating fossil you'll need to do a fossil rebuild on the repo to >>>> fill the new table. >>>> Currently the revision numbers are reflecting the fossil rebuild algorithm >>>> so they count down from leaves which is a bit odd, but that can probably >>>> be >>>> improved. >>>> >>> >>> this is already quite nice. but ultimately I think the best solution would >>> be to have the map revnum -> sha1 as drh indicated where the revnums are >>> just the chronological/auto-incremented index of the commits. >>> >>> >>> >> The fossil rebuild logic uses a two pass algorithm. I am not quite sure why >> this is necessary, it could have something to do with delta manifests. At >> http://mpcjanssen.nl/fossil/fossil/timeline?r=revlist I have changed this >> to a single pass. This results in relatively monotomic ids which should be >> stable across consecutive rebuilds. One caveat, this could break horribly >> when delta manifests are present so use at your own risk. > > > understood. what I do not get is (apart from that's it probably not part of the current machinery) why it > would be complicated (for the people in the know) to just log the checkins and count them while they arrive in the db (be it locally or by a pull) or, rather, to assign a revnum in chronological order (i.e. the order in which `fossil timeline' displays the checkins). and then put that > info in some table for the user to assess (and hopefully for the the fossil commands to accept instead of the hashes for identifying revisions). > is there a principal technical difficulty in doing that? > > j. > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/
Note that chronological and the order in which they get into the db are generally not equivalent in a DVCS. I think stability of the revs for a certain clone (with Stephan's caveats) is a good thing. There is no real reason why you can't initially generate them chronologically except that it would require more code in the rebuild command. Also if you pull older changes and rebuild revs will change. You should at least have enough now to try it out and see if it helps.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
