On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia <o...@integral.be> wrote:
> Hello, > > Coming from subversion where there is a revision number, incremented by > one by each commit, Let me be the first of many to say that those centrally controlled increments are not possible in a *distributed* source control system. Maybe a “feature branch” and your own heuristics would fit the bill? Cheers, -bch which is very easy to capture in automated builds to be injected as part of > the version number of binaries built... > > Revision 8745 -> version x.y.z.8745 > Revision 8789 -> version x.y.z.8789 > > The x.y.z is incremented by hand when it means something (release of some > tested version). But for the lifetime of a version, there might be some > newer builds (small fixes) and they will be auto-tagged with the revision > ID as last part of the full version number. > > In real life this can lead to sequences of file version numbers as: > > 1.2.3.8745 > 1.2.3.8749 > 1.2.4.8801 > ... > > This has many advantages, not the least being to easily spot which among > two binaries is more up to date (has simplifications in setup systems). The > main limitation is that (on Windows) those 4 parts of a full file version > id are each limited to 16 bits. Limiting this model to about 65.000 > revisions. After which some offset should be applied (which is easy to do > every time the first 3 values are hand changed). > > Of course this characteristic (a sequential revision ID) is logical in a > centrally managed system as subversion and is less trivial in distributed > scm like fossil or git. > > 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'). > > The full version string (as "1.2.4.8801") would then be automatically > added as a tag to the most recent check-in on trunk (from which the build > is derived). > > How does that sound to those of you who might have had similar concerns? > Been there and rushed away? Or happy to stay? > > -- > 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
