llvm dev - Dec 2018 - New LLVM git repository conversion prototype

On Wed, Dec 19, 2018, 13:21 David Greene via llvm-dev <
llvm-dev at lists.llvm.org wrote:
> [ Consider all of this to be preferences, not anything close to an
>   objection. ]
>
> Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > There haven't been many more responses in the last few days, so
can we
> > try to come to some kind of consensus here?
>
> I agree with others that this discussion doesn't have to delay the
> official repo from being posted.  Let's get that done ASAP.  Lots of
> people are waiting on it.
>
> > 1. Release tags.  There were a lot of small variation on the tag names
> for releases,
> > but it seems like the preferences was to use the llvm.org prefix,
> > so I'm going to propose using tag names like:
> >
> > llvm.org-8.0.0
> > llvm.org-8.0.0-rc1
> >
> > Any strong objections to this?
>
> SGTM.  I don't think we need a -final suffix or anything.  A straight
> version number seems to convey intent for many other projects.  But not
> a big deal either way.
>
> We almost certainly want annotated tags.
>
> > 2. Tags for commits in the master branch that bump the release
version.
> >
> > Most of the discussion about this so far has been on what to put after
> > the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint).
> > Other things to consider about this tag is that it might be used in
> > a git describe alias to identify commits, so it would be helpful if
> > it was short.
> >
> > One idea I had after reading through all the responses was to use the
> > -git suffix on the tags. e.g. v8.0.0-git.  It's short and it's
clear
> > that you are getting something that isn't an official release.  It
> > also is similar to the 8.0.0svn version number that we currently use
> > to indicate a non-released version.  Which of these 4 options(
> > dev, base, branchpoint, git) do people prefer?
>
Of these, -git seems the least misleading, based on responses so far
(branchpoint in particular). However, based on previous comments, I'm not
sure we want the specific format you suggested (see previous; it's missing
at least an llvm prefix namespace).

> I agree that -git or -dev could be misleading.  I also agree that we may
> not need this tag at all.

Strictly speaking, we don't *need* to switch to git, either. ;-) It's
worth
our time collectively (I claim) to get it right from the beginning; a
broken or wrong output from a built-in git command seems problematic.

If we want the tag, I thirdly agree that
> tagging the split point is more useful/convenient than tagging the
> version bump.
>
Tagging the split point is semantically the wrong thing, though: if you
`git describe` the last commit before the branch for release ${N} (i.e.,
the last commit of N), the descriptor will be ${N+1} (or whatever tag was
applied). The version bump commit will then be "${N+1}-1", meaning the
second commit of the N+1 release (with commit hashes as appropriate).
That's an off-by-one error in several ways. ;-)

Also note, the split point is trivial to reach from the version bump, but
not vice versa. It's reachable as ^ from the version bump tag, and also
(less trivially, but still without explicit set arithmetic) as merge-base.

An easy way to reason about this is that the version bump tag should only
be reachable from the release branch for that version. So if the 8.0 bump
is reachable from the 7.x release branch, that's going to result in `git
describe` attributing commits with the wrong version.

> I have a preference for an llvm.org prefix on this tag, just like for
> the release tags, for the same reason we have it there: namespacing to
> avoid downstream conflicts.  But it's certainly not a dealbreaker.
>
>                             -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181219/4bc5be64/attachment.html>

David Jones <dlj at google.com> writes:
> Tagging the split point is semantically the wrong thing, though: if
> you `git describe` the last commit before the branch for release ${N}
> (i.e., the last commit of N), the descriptor will be ${N+1} (or
> whatever tag was applied). The version bump commit will then be "$
> {N+1}-1", meaning the second commit of the N+1 release (with commit
> hashes as appropriate). That's an off-by-one error in several ways. ;
> -)
Ah, I forgot the primary purpose of this is for `git describe`.  Thanks
for clarifying.  You are absolutely correct as far as the semantics of
that operation.

                           -David

On Wed, Dec 19, 2018 at 8:05 PM David Jones via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Wed, Dec 19, 2018, 13:21 David Greene via llvm-dev <llvm-dev at
lists.llvm.org wrote:
>> I agree that -git or -dev could be misleading.  I also agree that we
may
>> not need this tag at all.
>
>
> Strictly speaking, we don't *need* to switch to git, either. ;-)
What I meant was that I don't see why we need this in order to switch
to git. Getting nice git-describe results seems nice, but is it
necessary? I've never used it myself, so I'm not that familiar with
it.

If we just want the ability to refer to trunk commits by number,
couldn't we just tag the initial commit as "genesis" and
git-describe
against that?
> Tagging the split point is semantically the wrong thing, though:
It can't be semantically wrong if the tag correctly describes the
commit it's applied to.

That's my objection to tagging the version bump with things like
"8.0.0-dev": the name implies that the commit is the development
version of 8.0.0, which it's not.

If we do tag the version bump, I think the name has to be something
like "8.0.0-base" or "8.0.0-first", to correctly describe
the commit
it's tagging.
> if you `git describe` the last commit before the branch for release ${N}
(i.e., the last commit of N), the descriptor will be ${N+1} (or whatever tag was
applied). The version bump commit will then be "${N+1}-1", meaning the
second commit of the N+1 release (with commit hashes as appropriate).
I'm having trouble following the maths here, but if we tag the
branchpoint, say "7.0.0-branchpoint", then the commits on trunk after
that, i.e. the development of 8, will be described as "n patches after
7.0.0-branchpoint" which seems entirely correct to me: version 8 is
stuff landed after the branchpoint for 7".
> An easy way to reason about this is that the version bump tag should only
be reachable from the release branch for that version. So if the 8.0 bump is
reachable from the 7.x release branch, that's going to result in `git
describe` attributing commits with the wrong version.
I don't understand this part. Why would the 8.0 bump be reachable from
the 7.x release branch? The version bump happens after the branch is
created.


Anyway, all I'm saying is that if we add tags, the name must match
what the commit does. Tagging the version bump with "8.0.0svn" or
"8.0.0-dev" or similar doesn't do that.

 - Hans

> If we just want the ability to refer to trunk commits by number,
> couldn't we just tag the initial commit as "genesis" and
git-describe
> against that?
This works only for trunk; branches would re-use commit numbers, if
we count from the beginning of time.

In my company's repo, for branches we count from the branch point.
This makes the numbers for trunk and branches different enough that
we can easily tell the difference.
> If we do tag the version bump, I think the name has to be something
> like "8.0.0-base" or "8.0.0-first", to correctly
describe the commit
> it's tagging.
Seems reasonable to me.
> > if you `git describe` the last commit before the branch for release
${N}
> (i.e., the last commit of N), the descriptor will be ${N+1} (or whatever
> tag was applied). The version bump commit will then be
"${N+1}-1", meaning
> the second commit of the N+1 release (with commit hashes as appropriate).
> 
> I'm having trouble following the maths here, but if we tag the
> branchpoint, say "7.0.0-branchpoint", then the commits on trunk
after
> that, i.e. the development of 8, will be described as "n patches after
> 7.0.0-branchpoint" which seems entirely correct to me: version 8 is
> stuff landed after the branchpoint for 7".
But commits on the 7.0.0 branch would *also* be described as "n patches
after 7.0.0-branchpoint" because the branchpoint is the common ancestor
of both branches.  I think that ambiguity in `describe` is not a good idea.

If we have a tag for the branchpoint, we also need one for the bump,
which would be reachable on master and not from the branch.
> > An easy way to reason about this is that the version bump tag should
> only be reachable from the release branch for that version. So if the 8.0
> bump is reachable from the 7.x release branch, that's going to result
in
> `git describe` attributing commits with the wrong version.
> 
> I don't understand this part. Why would the 8.0 bump be reachable from
> the 7.x release branch? The version bump happens after the branch is
> created.
I also don't understand this part. The version bump is done on
"master"
after the branch is created, yes? Ideally it's the first commit on master
that is *not* reachable from the 7.x release branch.

--paulr

On Thu, Dec 20, 2018 at 1:35 AM Hans Wennborg via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Wed, Dec 19, 2018 at 8:05 PM David Jones via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > On Wed, Dec 19, 2018, 13:21 David Greene via llvm-dev <
> llvm-dev at lists.llvm.org wrote:
> >> I agree that -git or -dev could be misleading.  I also agree that
we may
> >> not need this tag at all.
> >
> >
> > Strictly speaking, we don't *need* to switch to git, either. ;-)
>
> What I meant was that I don't see why we need this in order to switch
> to git. Getting nice git-describe results seems nice, but is it
> necessary? I've never used it myself, so I'm not that familiar with
> it.
>
> If we just want the ability to refer to trunk commits by number,
> couldn't we just tag the initial commit as "genesis" and
git-describe
> against that?
>
> > Tagging the split point is semantically the wrong thing, though:
>
> It can't be semantically wrong if the tag correctly describes the
> commit it's applied to.
>
> That's my objection to tagging the version bump with things like
> "8.0.0-dev": the name implies that the commit is the development
> version of 8.0.0, which it's not.
>
> If we do tag the version bump, I think the name has to be something
> like "8.0.0-base" or "8.0.0-first", to correctly
describe the commit
> it's tagging.
>
> > if you `git describe` the last commit before the branch for release
${N}
> (i.e., the last commit of N), the descriptor will be ${N+1} (or whatever
> tag was applied). The version bump commit will then be
"${N+1}-1", meaning
> the second commit of the N+1 release (with commit hashes as appropriate).
>
> I'm having trouble following the maths here, but if we tag the
> branchpoint, say "7.0.0-branchpoint", then the commits on trunk
after
> that, i.e. the development of 8, will be described as "n patches after
> 7.0.0-branchpoint" which seems entirely correct to me: version 8 is
> stuff landed after the branchpoint for 7".
>
> > An easy way to reason about this is that the version bump tag should
> only be reachable from the release branch for that version. So if the 8.0
> bump is reachable from the 7.x release branch, that's going to result
in
> `git describe` attributing commits with the wrong version.
>
> I don't understand this part. Why would the 8.0 bump be reachable from
> the 7.x release branch? The version bump happens after the branch is
> created.
>
>
> Anyway, all I'm saying is that if we add tags, the name must match
> what the commit does. Tagging the version bump with "8.0.0svn" or
> "8.0.0-dev" or similar doesn't do that.
>
I see the "tagging" not much differently than the commit where we
change
the version number in the CMakefile, so I would tentatively tag this bump
for consistency?

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190103/20ffb2cf/attachment.html>