Re: [fossil-users] Replacing subversion revision number... by what?

[David Mason]

Days since start of the release branch would seem like a good proxy -
assuming you create release branches (which seems like a good idea):
1) increasing
2) small number - you could use hours instead of days if you release
multiple versions per day
3) pretty directly mappable to a commit.
4) same on any machine
​
../Dave
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Replacing subversion revision number... by what?

[Roy Keene]

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  wrote:

Le 28 déc. 2017 à 23:58, Joerg Sonnenberger  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

Re: [fossil-users] Replacing subversion revision number... by what?

[Olivier Mascia]

Le 29 déc. 2017 à 17:04, Mark Janssen  a écrit :
> 
> 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?

Irrelevant, to me.
As said, no public released code will get out of anywhere except from a 
dedicated repo (let’s call it the root one) from which development repo are 
cloned from.

We’re not in an open-source scenario where anybody would build a 
public-distributed binary out of his own local repo. Anyone with code access 
(right to clone repo) can build a release build (for testing purposes for 
instance), but such a build would not be publicly distributed, if only because 
it couldn’t be EV code signed (no access to private keys to do so).

Well in between of these exchanges I could complete the overhaul of our 
production build automaton and this technique fits the bill nicely.

So thank you all for your valuable inputs on the matter. They not always 
applied to the specific concern, but were very interesting in all cases.

Season’s greetings to all of you,
-- 
Best regards, Meilleures salutations, Met vriendelijke groeten,  
Olivier Mascia (from mobile device), http://integral.software

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Replacing subversion revision number... by what?

[Mark Janssen]

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  wrote:
>> Le 28 déc. 2017 à 23:58, Joerg Sonnenberger  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

Re: [fossil-users] Replacing subversion revision number... by what?

[Olivier Mascia]

> Le 28 déc. 2017 à 23:58, Joerg Sonnenberger  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

Re: [fossil-users] Replacing subversion revision number... by what?

[Joerg Sonnenberger]

On Wed, Dec 27, 2017 at 11:56:31PM +0100, Olivier Mascia wrote:
> > Le 27 déc. 2017 à 23:24, Joerg Sonnenberger  a écrit :
> > 
> > On Wed, Dec 27, 2017 at 10:10:21PM +, bch wrote:
> >> On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia  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.
> > 
> > That's not completely true. You could use the length of the commit chain
> > to the root for most of the purposes of the CVS/SVN revision number.
> > It's just not necessarily a unique property of a commit.
> 
> Thanks Joerg.
> 
> >> 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?

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Replacing subversion revision number... by what?

[Warren Young]

On Dec 27, 2017, at 4:42 PM, Warren Young  wrote:
> 
> What it’s going to give you is a short prefix of the Fossil checkin ID

On reading the script, it depends on being installed in a directory one level 
below the checkout root.  I have it in a “tools” subdirectory of that 
particular repository, where I place all non-installed scripts and helper 
executables, but the depth is all it really cares about.  If you place it 
somewhere else, you might change all the references to “tools/“.  If you place 
it deeper than one level or outside the repository, you’ll also have to adjust 
the path manipulation code.

It depends on that project’s release version tagging scheme, done by 
tools/mkrel, which you might also find interesting.  Release version tags in 
this project are of the form “v20171227”: if you run this script on a checkout 
so tagged, you get that tag as output, which you can use anywhere in Fossil 
that you could use a checkin ID.

If you run it anywhere else in the repository, it gives you a string like 
“id[abcde12345]”, which makes it easy to visually distinguish from a version 
tag.

The “else” clause tries to deal with the case of building from a source 
tarball, but it’s only capable of coping with our release tarball naming scheme.

If nothing else, this script should give you some ideas for replacing it with 
something you find more useful.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Replacing subversion revision number... by what?

[Warren Young]

On Dec 27, 2017, at 4:42 PM, Warren Young  wrote:
> 
> Here’s one my solutions to problems of this sort:
> 
>https://tangentsoft.com/pidp8i/artifact/b7c1181a86483d86

Better URL: https://tangentsoft.com/pidp8i/file/tools/version

> run it within the repository

I mean the checkout directory, of course.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Replacing subversion revision number... by what?

[Warren Young]

On Dec 27, 2017, at 3:06 PM, Olivier Mascia  wrote:
> 
> Coming from subversion where there is a revision number…

I’ve made the same move with three separate repositories, and each time such a 
question has come up, I’ve chosen to simply not try to replicate the Subversion 
way of doing things, but instead to use what Fossil already provides.

Here’s one my solutions to problems of this sort:

https://tangentsoft.com/pidp8i/artifact/b7c1181a86483d86

Just copy the script to your local machine and run it within the repository.  
It’s free software and easy to adjust to taste.

What it’s going to give you is a short prefix of the Fossil checkin ID instead 
of a monotonically increasing revision number.  These won’t sort, and they 
don’t tell you how far two checkins are apart from each other by simple 
subtraction, but you *can* use them with commands like info and Fossil UI pages 
like /info to pull up details about the commit IDs you’re looking at.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Replacing subversion revision number... by what?

[Olivier Mascia]

> Le 28 déc. 2017 à 00:07, bch  a écrit :
> 
> The chain-length method Joerg mentioned is roughly what I was thinking, 
> bounded to a single branch “namespace” to manage disambiguation. Mind, this 
> is off the top of my head, not a thing I’ve implemented.


Thanks Brad.
-- 
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

Re: [fossil-users] Replacing subversion revision number... by what?

[bch]

On Wed, Dec 27, 2017 at 2:23 PM Olivier Mascia  wrote:

> > Le 27 déc. 2017 à 23:10, bch  a écrit :
> >
> > On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia  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?
>
> Brad, I think I know that and wrote it in my message.


So you did, my apologies.

The chain-length method Joerg mentioned is roughly what I was thinking,
bounded to a single branch “namespace” to manage disambiguation. Mind, this
is off the top of my head, not a thing I’ve implemented.

Kind regards,

-bch



> The question was indeed about my proposed heuristic to use the count of
> check-ins:
>
> > 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

Re: [fossil-users] Replacing subversion revision number... by what?

[Joerg Sonnenberger]

On Wed, Dec 27, 2017 at 10:10:21PM +, bch wrote:
> On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia  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.

That's not completely true. You could use the length of the commit chain
to the root for most of the purposes of the CVS/SVN revision number.
It's just not necessarily a unique property of a commit.

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Replacing subversion revision number... by what?

[Olivier Mascia]

> Le 27 déc. 2017 à 23:10, bch  a écrit :
> 
> On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia  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?

Brad, I think I know that and wrote it in my message.
The question was indeed about my proposed heuristic to use the count of 
check-ins:

> 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

Re: [fossil-users] Replacing subversion revision number... by what?

[bch]

On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia  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

[fossil-users] Replacing subversion revision number... by what?

[Olivier Mascia]

Hello,

Coming from subversion where there is a revision number, incremented by one by 
each commit, 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