Mark,
The main thing that a hash doesn't give you is ordering -- you
don't know if aed2 is before or after f9a2, c93a, etc.
When I migrated from Subversion to Fossil, I just used the datecode for
this value since that preserves ordering. On other projects I moved to
explicit version numbers tagged with a release since the tag already had
to be coordinated.
Thanks,
Roy Keene
On Fri, 29 Dec 2017, Mark Janssen wrote:
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
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
