Re: [lmi] [lmi-commits] master 53e1802 4/8: Use a gainlier name for source directory

[Greg Chicares]

On 2017-05-21 17:13, Vadim Zeitlin wrote:
> On Sun, 21 May 2017 17:03:06 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I don't have any tags. I used them in svn, but I'm not sure that's an
> GC> svn feature that I really miss.
> 
>  Tag implementation in svn is a horrible hack (nobody in their right mind
> thinks of tags as a copy of the sources in a specially named directory),
> but the concept of tags is very useful and, while I didn't want to bring
> this into discussion, I definitely think that they should be used for lmi,
> e.g. for all the monthly releases.

That sounds good, especially because Kim often wants to build a designated
lmi release candidate, which is not always HEAD; and lmi already has a
'release_candidate' makefile target, which updates 'version.hpp' and
used to (instruct us to manually) create an svn tag.

>  If you do decide to start using them, please notice that understanding git
> tags is not as straightforward as it could be, because git uses this word
> to describe two rather different things: local, lightweight tags (which are
> also useful, but probably not with your workflow) and public, annotated
> tag. You want the latter and you probably also will want to sign them with
> your GPG key for the usual integrity reasons, so you could just use a
> command like the following:
> 
>       $ git tag -s -m 'Tag 2017-05 release' v2017.05

Okay, I'll look into that, though not right now.

> GC> >  In fact, I think it would be nice(r) to use this string as part of the
> GC> > vendor string too.
> GC> 
> GC> Yes, that's icky, too, and ought to be improved. I changed one of them 
> because
> GC> I needed to add a file that would otherwise have been named
> GC>   wx-41045df7ea5f93e4c07c1bd846d7127a372705bd.patch
> GC> but that was just a temporary expedient. I'm willing to consider a general
> GC> improvement in these names. But, returning to the example above, why 
> would the
> GC> second string be more helpful than the first?
> GC>   3.1.0-p1             [first]
> GC>   v3.1.0-1337-g33b0a70 [second]
> 
>  Note that I said that it should be used as _part_ of the vendor string,
> not its entirety -- the "p1" part is important too. So I would just
> concatenate both of them together and use "v3.1.0-1337-g33b0a70-p1".
> 
> GC> The first means it's wx-3.1.0 with lmi patch 1. Does the second mean...
> GC>   wx-3.1.0
> GC>   1337 commits after...
> GC>   g33b0a70 ...this sha1sum?
> 
>  Yes, exactly ("g" is not part of SHA-1 though).

I have to ask--what does "g" mean, then? Does it stand for something,
like the "g" in "debuG"? Or is it just the first alphabetic character
that is not a hex "digit"?

> GC> I can see how that could be useful if you build wx frequently and retain
> GC> various versions of it, but I build wx rarely and erase old versions. If I
> GC> want to know what the sha1sum is, I can look that up in the lmi makefile.
> 
>  Vendor tag is embedded in the DLL names, so it provides a very simple
> way to check which wx version is used, which is nice IMO.

Yes, I now see how that could be valuable.

> It is also
> automatically unique, so different DLLs will never have the same name.

Is uniqueness guaranteed absolutely, or probabilistically? I had been
using 40-character sha1sum strings because that question is expected
never to arise. I'm reluctant to use 7-character sha1sums because
collisions are quite possible. But maybe that doesn't actually matter.
If I ask git for the abbreviated sha1sum, it'll return something that's
as short as possible, but no shorter: it's guaranteed to be distinct
from any *earlier* sha1sum in the same repository, so we might say it's
absolutely guaranteed to be backward-unique.

It is by no means guaranteed to be forward-unique, but that doesn't
matter. We might try a new version of wx, and then find a problem that
causes us to revert back one step to the last version we were using;
but I can't imagine that we'd every revert more than one step. Thus,
if we upgrade to 33b0a70 today, it doesn't matter if in the year 2020
we upgrade to 33b0a70e (with an extra character on the end), because
we aren't going to revert three years back to a 2017 commit.