All of this will fail in the case of private branches (or other DAG differences) between different repositories, unless you special case private branches. And how will you handle diverging repos so that my version 12 is not your version 12, because I didn't sync after commit 10? I wouldn't be surprised if it's mathematically provable that to create a unique id for a distributed DAG, the only way is to make one repository special (e.g. the centralized SVN scenario)
Which begs the question, why all this effort to create something which already is there? Is stating version 1245 really that much easier than stating version aed2 ? On Fri, Dec 29, 2017 at 11:12 AM, Olivier Mascia <o...@integral.be> wrote: >> Le 28 déc. 2017 à 23:58, Joerg Sonnenberger <jo...@bec.de> a écrit : >> >>>>> I'm considering replacing the subversion revision ID, for the purpose of >>>>> defining the file version ID (as above) at release-external build time, >>>>> by the count of check-ins in the root repository. That is the count >>>>> returned by 'fossil info' in one of the multiple lines of output (for >>>>> instance 'check-ins: 8801'). >>> >>> My 'count of check-ins' is your 'length of the commit chain to the root', >>> or are we talking of something else here? >> >> If you have a commit graph like: >> >> A >> | >> B >> | \ >> C D >> | | >> E F >> >> Both E and F have a LoCC of 4, but the count f check-ins would depend on >> the order of commits? > > That I don't know yet for sure. > > I just want an integer, always increasing, even though not by one, from a > specific branch, from a specific repository (the branch/repository from which > I compile released code). And that value seems to fit that need perfectly. > It does not need to allow me backward lookups (finding a check-in from that > number). That sequential number could even be managed outside by my build > system. But it is interesting that it be linked with the count of check-ins, > because somehow it gives an empiric sense "of the distance" of code between > to release builds. Which we had before through the subversion revision ID. > > Upon build I will derive the trailing version number of my executables from > that integer. And my build system will auto add a tag with the full > constructed version number to the top check-in of that same branch. I can > also store that top check-in ID (hash) somewhere else (than in the version > number) so it could be displayed on request. And there, thanks to the > auto-added full version number tag upon successful release build, I get an > easy way to locate the exact source code that was part of that build. It's > easier for users to tell support people their version number than a hash > code, even shortened. And setup/distribution is easier thanks to an ever > increasing full version number, even between patch builds of a same release. > > -- > Best Regards, Meilleures salutations, Met vriendelijke groeten, > Olivier Mascia > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
