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): > > having simple chronological checkin numbers as an alternative way of > specifying checkins _locally_ just the way hg has done for years would be > a *good* thing. simply because for most projects (all the small ones out > there) specifying chronological numbers is shorter/easier than specifying > (unique min 4-digits prefixes of) sha1 hashes. and the "chronologic > property" itself is helpful in itself, e.g in comparing 'current vs. > previous' checkin. and until checkin 9999 its at least break even in terms > of typing effort. the fact that those chronological checkin numbers are a > local property of each clone/checkout rather than of the repo proper is > beside the point in my view: it is true but mostly irrelevant. I concede > that there might arise confusion if people are really not aware of the > potential ambiguity of those chronological numbers across different clones > if they start to argue about a certain checkin. but when interacting with > fossil it cannot have adverse effects afaiks. rather the opposite. 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. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
