Re: serial lines -- a proposal

[Filippo Giunchedi]

[sorry for being silent since this summer, real life calls sometime :)]

On Fri, Dec 25, 2009 at 10:51:59PM +0100, Peter Simons wrote:
> Hi guys,
> 
> I've committed a small script, set-serial.sh, that might allow us to provide
> reliable serial numbers for all our macros automatically. To try it out, just
> run:
> 
>   ./set-serial.sh m4/*.m4
> 
> The serial number assigned to a given m4 file corresponds to the number of
> commits that modified that particular file. Consequently, *every* modification
> results in a serial number bump. It's trivial to integrate that script into 
> the
> Archive's build process. Come release time, that would guarantee reliable
> version information in every m4 file.

sounds good to me, I'm not entirely convinced by increasing at every commit vs
increasing only on changes on non-comments though.
How it is intended to be used? Before release serialize everything then commit
then tag?

Anyhow, you can use git log --oneline and count lines, that will hardly make a
difference :)

> Personally, I feel that this approach is good enough(tm) for all practical
> purposes. There is one conceivable scenario, though, that might spell trouble
> for this scheme. Imagine that someone downloads a macro, modifies it, and
> re-releases that file using a serial number that's a *lot* higher than the one
> we used. If we'd import those changes back into the Archive, then our scheme
> would end up assigning the file serial numbers that are lower. Consequently,
> aclocal would falsely refuse to update that macro.

Indeed, what if there's a note to increase the serial in a way that sorts in
the middle between ac releases? Judging from aclocal code it seems that a
trailing dot would be enough, i.e. 4. > 4 or for that matter 4.number > 4 of
course

filippo
-- 
Filippo Giunchedi - http://esaurito.net - 0x6B79D401

Frustra fit per plura, quod fieri potest per pauciora.
It is vain to do with more what can be done with less.
-- W. of Ockham