Re: [Monotone-devel] m7 rises from the dead... reborn with new non-irritating behavior!

[Ulf Ochsenfahrt]

Hugo Cornelis wrote:
> heccer-passive-1.tar.gz
> heccer-passive-2.tar.gz
> heccer-passive-3.tar.gz
>
> and
>
> heccer-active-1.tar.gz
> heccer-active-2.tar.gz
> heccer-active-3.tar.gz
>
> and so on.
>
> This automates building releases, and avoids human errors.  The
> release number is saved in a small database, currently included in the
> project, such that a next release number can be generated from the
> database.  The downside is that this database is committed with the
> project and that a tag is set on the previous revision, after
> incrementing the version number.  Both these operations can possibly
> fail and leave the system in an inconsistent state, because the
> repository is kind of ahead of the released package.  This is just a
> minor issue, but it makes me feel uncomfortable.
>
> So far the script works without problems.  I am just wondering about
> the relationship between what you have done and what I have done ?
> Can I use your versioning method in combination with my keyword
> expander and build automake packages for heccer and neurospaces
> automatically ?  Can I use m7 and monotone interchangebly for monotone
> functions ?  I.e. I only have to call m7 to get the version number ?

The problem with local revision numbers, AFAICT, is that they are, 
indeed, local. You can't ever make a release from a different machine. 
You can't even move to a different machine yourself*. And when monotone 
changes its internal storage, all kinds of things can go haywire.

In short:
Don't use local revision numbers to construct (apparently) globally 
unique revision numbers. It doesn't work.

In general, you can't guarantee monotonely (a pun?) increasing revision 
numbers in a distributed system. Ever. What might work for you is some 
combination of
 1) allowing only a single person to make releases
    (other people making releases are punished by ignorance)
 2) using a file in the repository that contains the current release number
 3) I'm sure there are other ways, and someone will hopefully be so 
nice as to point them out.

If you happen to want releases with local revision numbers, go ahead and 
use Larry's script. Just don't complain if something breaks because of 
the above. You have been warned.

Cheers,

-- Ulf

PS: This post is not meant as a thrashing, just well-intended advice.

* Except if you make an bitwise exact copy of your archive.

smime.p7s
Description: S/MIME Cryptographic Signature