On 10 September 2015 at 15:17, j. van den hoff <veedeeh...@googlemail.com> wrote: > On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal <sgb...@googlemail.com> > wrote: > >> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein <bmburst...@gmail.com> >> wrote: >> >>> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff < >>> veedeeh...@googlemail.com> wrote: >>> >>>> in a breach of promise to myself to never again argue in favour of this >>>> functionality on the fossil mailing list (it came up a few times over >>>> the >>>> last years): >>> >>> >>> If I understand correctly, the way fossil is designed could cause the >>> numbers to change *even locally* upon a rebuild, or even just a sync. >>> This >>> would probably get confusing. >>> >> >> Correct. And if i'm not mistaken, if you rebuild with the --randomize >> option then the order could get even weirder. > > > well, I'm only talking about the ordinal numbers chronologically enumerating > the timeline checkin(!) entries. this enumeration will not change as a > consequence of rebuild, right? it might change after a sync against some > remote repo if there are incoming checkins chronologically interleaved with > my own, sure, but so what? the relative numbers would be just a (somewhat > "volatile") convenience measure _locally_. and I agree with another recent > post that this would primarily concern the CLI. what I mean: go ask some hg > users when they last did use sha1 hashes for specifying checkins in their > interaction with hg (which supports both the ordinals as well as the hashes > for doing so) and how often the presence of those numbers confused > communication with other developers in their project. I'm quite sure they > _never_ specify sha1 hashes to denote checkins in any small to medium-sized > project below 10^4 checkins (currently > this still includes fossil itself). not so sure about the "communication" > issue if users forget the potentially 'volatile' nature of the relative > enumeration, but this just can't possibly be a big issue ... > > I therefore just maintain it would be "nice to have". it sure ain't a killer > feature, I admit ... >
Given that fossil does not support history rewriting by design the commit number on a particular branch counting from root is unique and stable per branch across all repos. If you release from a single master branch you have a monotonous snapshot number. When you use multiple branches you need to add branch name to have stable unique identifier. This is not viable eg. for git with rebasing. Thanks Michal _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
