On Tue, Dec 03, 2019 at 09:16:43AM +0000, Richard Earnshaw (lists) wrote:
> On 03/12/2019 00:56, Segher Boessenkool wrote:
> >That sounds simpler than it is... After using this for a while you'll
> >get names that you want to delete, but that name *already* is in
> >/refs/deleted. So what will you name it then? People will still need
> >to be able to find it.
> >
> >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.
> 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.
> You only have to run 'svn ls' on the current gcc branches directory in
> SVN to realize just what a mess our current naming scheme it, so I'd
> also suggest that we do some general reorganization of the other
> branches/tags we have, especially if we have a /refs/svn namespace after
> conversion:
>
> a) Only live development branches get moved to the normal git namespace,
> but see d) & e) below
Yes, I called it "old-svn" for a reason. One idea is to move *everything*
there, and let people make a copy to the "live" stuff if they want it.
And we can pre-populate the things we know are still used, of course, and
all release branches (closed or not), that kind of thing. But we could
just shovel all that is in SVN into some nice tidy subdir, that normal
people never have to look at again :-)
> b) vendor branches should move to something like
> refs/vendors/<vendor>/{heads/tags} (these won't be pulled by default by
> a normal clone, you'd have to add an explicit map request to see them.
> c) user branches should only be in something line
> refs/users/<userid>/{heads/tags} (similar to above)
Yup.
> 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?
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"?
> That probably means the top-level heads/tags spaces are empty; but I
> have no problem with that.
It is good when people get the most often used things immediately.
Segher
