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.
> >> 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.
> >> 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"?
To make it clear that these are "official" the release tags should be
signed with an "official" key, of course ;-)
> > 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?
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.
Segher
