On Thu, Sep 10, 2015 at 03:29:24PM +0200, Michal Suchanek wrote: > 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.
Even in fossil it could be a problem, it cannot re-write history but a branch is just a tag that can change. The identifier will change after moving checkins on a branch. -- Martin G. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
