On 03/12/2019 22:43, Segher Boessenkool wrote:
On Tue, Dec 03, 2019 at 08:10:37PM +0000, Richard Earnshaw (lists) wrote:
On 03/12/2019 18:56, Segher Boessenkool wrote:
On Tue, Dec 03, 2019 at 09:16:43AM +0000, Richard Earnshaw (lists) wrote:
But we could make an "old-svn" hierarchy or similar that just has
everything svn has now (and will never change, so it will never cause
conflicts).
Well that's true of /any/ renaming scheme for dead branches.
No, it is not. If you have a simple "deleted" hierarchy, to which you
add things, you will get conflicts. If you have one just for things
imported from SVN, it will never change (since SVN is set in stone after
the conversion), and there will not be conflicts.
But you've still got the ongoing branch death issue to deal with, and
that was my point. If you want to keep them, and you don't want them
polluting the working namespace, you have to do *some* renaming of them.
Sure, but how many of those will there be? This is a different scale
problem from that with the SVN branches and tags, which makes it a quite
different problem.
Over time, likely as many, if not more than for svn. In GIT branch
development is the norm for most developers. It's true that most of
those are private and get serialized before upstreaming (unless we move
to a different development model, but that's a different discussion),
but we will likely have at least as many public development branches in
git as we've ever had in SVN.
There's
nothing special about this one. On the other hand, there's nothing that
says that the renamed branch has to have exactly the same name as the
live one: it's a rename after all.
Renamed tags and branches are *useless*, we could just as well delete
them completely, if people can no longer find them.
They can be found, it's just that they don't appear in the standard list
since they aren't pulled by default from the upstream repository. It's
no different from the situation where if you clone from a clone, the
things in the local repository that are in refs/remotes are not pulled
into the secondary clone, unless you add an explicit fetch entry to your
remote's configuration, something like
[origin]
...
fetch = refs/deleted/*:refs/remotes/origin/deleted/*
No. If you rename a branch, you have to look at all thousands of branches
to see which one might be the one you wanted. Something with a similar
name hopefully?
I'm not saying things moved into some separate hierarchy. That is fine.
But that *will* give conflicts if you keep doing that on a live repo,
and then you *do* need real renames.
And you then cannot refer to things by name anymore. Which is the common
way we refer to anything.
The problem of naming can be pretty much solved by either putting the
year name in the branch when its created, so instead of 'fred' you
create 'fred_2020'. Now names are unique as long as you don't have two
in the same year; alternatively, you can add the date as part of the
renaming process as the branch dies - more likely then it would be the
year of closure. Either way, finding them is not hard later on, since
the prefix part is unchanged.
The other way to solve it is documentation. We have a web page which is
*supposed* to list all the development branches we have. When a branch
is renamed, the rename can be listed alongside the mark that the branch
is now dead.
d) releases should go into refs/{heads/tags}/releases (makes it clearer
to casual users of the repo that these are 'official')
What are releases? Release branches?
branches in the heads space, tags in the tags space.
Release branches and releases are a very different thing. A release
is some fixed source, like a tarball. A release branch is a branch, and
what code that is can (and will, and does) change.
Not that I have good suggestions how to make this less confusing. Well,
maybe we should keep calling it "gcc-9-branch" and "gcc-9_2_0-release"?
Branches are branches and appear in the heads name space, tags are tags
and appear in the tags name space. There's no way of confusing the two.
Plus, branches leave off the digits that aren't fixed during the life of
the branch. And if the branches are called releases/gcc-9 and the tags
releases/gcc-9.2 (no need for _ anymore, that's an anachronism from the
CVS days) then there's no ambiguity anyway.
To make it clear that these are "official" the release tags should be
signed with an "official" key, of course ;-)
Orthogonal to the git conversion, obviously they need signing; and
possibly we should restrict ability to move/rename branches in the
releases space to release managers to avoid accidents. I don't know if
that's feasible, but it's quite likely that it is.
It would be very inconvenient to not have the recent releases immediately
accessible, fwiw, but those could be just a copy. And then delete that
one after a branch is closed?
e) other general development branches in refs/{heads/tags}/devt
What does this mean? "other", "general"?
Anything that's not vendor/user specific and not a release - a topic
branch most likely
Should we often have those? We can just use user branches for this?
It depends. Some branches are definitely collaborations, so probably
want to be more public. I'm trying not to be prescriptive in this regard.
We *want* to rebase etc. on topic branches: allow non-fast-forwards.
And that is *very* problematic if multiple people can write to that
branch.
Rebasing a publicly visible branch is a no-no. It causes carnage for
anyone trying to track it. But this is straying into development
workflows again, and that's not for discussion during the conversion
(feature creep).
R.
