On Wed, 6 May 2020 at 11:00, Florian Weimer <fweimer@xxxxxxxxxx> wrote:
>
> >> >> Tags can also be added retroactively and backdated. These things
> >> >> conflict with the advantages you list (in particular, with NVR
> >> >> auto-generation, git is not the sole source of truth).
> >> >
> >> > If the tag ordering function is done properly, I believe even
> >> > retroactive tagging (i.e. tagging into past) and/or tag backdating
> >> > would be supported and NVR auto-generation would work correctly. So I
> >> > don't think it needs to conflict. But can you perhaps expand more on
> >> > "Tags can also be added retroactively and backdated", please?
> >> > I.e. why/when would one do that.
> >>
> >> No, you can push tags with incorrect dates. This can change the
> >> auto-generation.
> >
> > It really depends on what the tag ordering function is. If the
> > function does not consider dates at all, this wouldn't be a problem.
>
> The commit graph is ordered, but everything else is not. Tags (whether
> annotated or not) are outside the commit graph, so their order is not
> fixed.
Well, the assumption is that the order of tags will become fixed by
our tooling, i.e. that we will supply the ordering.
>
> I think this is different with Mercurial, where tags are part of the
> commit graph.
Interesting, I will look into it.
>
> >> You can only avoid this if you use data from commits (both current and
> >> earlier) *on the same branch* exclusively for generating metadata (or
> >> hash-linked from there). Everything else can get of sync and change
> >> over time even if the commit hash stays the same, so the repository
> >> state at a specific commit hash is longer the sole source of truth.
> >> (Because you need to reconstruct that other state *at the right time*.)
> >
> > What do you mean by "everything else which can get out of sync and
> > change"? If you are talking about tags (or refs in general), it's true
> > that you can add tags into past which may or may not affect
> > auto-generation depending on the ordering function.
>
> What kind of ordering function could tell apart a retroactively added
> tag and one that was there when the build was submitted?
Generally speaking, yes, N-V-R and changelog will be affected by
adding a tag retroactively.
I.e. you build some commit, you add some tag, you build the same
commit again => NVR and changelog can now be different.
What can be done here, is that when we build from a tag, build system
will pass that tag name (or tag object ID) to the tooling through
environment so the tooling will use that provided tag as the "latest
one" instead of identifying it through sort.
I.e. if you build from a tag, you will always get the same N-V-R over
and over again, no matter what happens in time. You can get a
different changelog, however, if someone tags some older commit by an
older version, i.e. my current version of software is foo-1.1-3 but
someone wants me to do an official release/build of an older version
for some reason, so i'll tag an old commit with e.g. foo-1.0-2 and the
changelog record for foo-1.0-2 will now additionally appear in all new
builds.
But I personally think that N-V-R uniqueness is a more important
property than N-V-R sameness when you build the same commit across
time repeteadly. N-V-R sameness for tagged commits can be implemented
by adding a special handling of tag/release builds as opposed to
testing commit builds for which N-V-R sameness won't hold. Changelog
sameness can't also be assured (at least not easily) but it may or
might not be an issue.
By N-V-R uniqueness I mean that you can't get the same N-V-R for two
builds of two different commits.
>
> >> That's why I proposed to auto-generate release numbers and changelogs
> >> based on the commits going back to the last Release: line and %changelog
> >> section update in the spec file. That would be stable (unless the tool
> >> changes how it generates those spec file parts).
> >
> > I don't think you can automatically generate %changelog and Release
> > and at the same time base their auto-generation on their last change
> > in spec file in git history. That somehow doesn't seem that it would
> > work.
>
> I don't know of any problems, and I have implemented this in the past
> (although in a very different context).
I would need and like to see the implementation so that I understand
what you meant exactly.
>
> > Tagging into past is imho rather a theoretical use-case but useful to
> > consider.
>
> Is it? It can easily happen if you forget to push a tag and then do a
> build, and push it later.
Well, if you don't push the tag and you do a build, you will get N-V-R
like foo-1.0-1.git.3.abcdef12. E.g. it won't be a clean N-V-R because
it doesn't come from a tagged commit. If you push a tag and repeat a
build from that same commit (or from that tag, see above), you will
now get a clean N-V-R like foo-1.0-2. This is assuming Release: {{{
git_dir_release }}} is used in the spec file to enable the automatic
generation of release. The annotated tags represent releases. if you
build an unreleased commit, you get a "work-in-progress" N-V-R and
also changelog won't be populated with the latest changes. This
workflow needs "pushing a tag" to be a build trigger so that it is
convenient.
Best regards
clime
>
> Thanks,
> Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
