On 10 September 2015 at 16:54, Martin Gagnon <eme...@gmail.com> wrote: > 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. >
If you can remove the tag that denotes the branch name from a branch and put it on another branch then the repo-unique identifiers will change since the branch name part will change, of course. The branch-unique identifier is stable, however. It can for example denote commits on currently checked out branch fine. And even with the ability to rename branches the branch name+commit number identifier is unique at any given time. Just not stable wrt branch rename which is understandable. Thanks Michal _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
