Re: Branch and tag deletions

["Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>]

On 03/12/2019 00:56, Segher Boessenkool wrote:
> On Mon, Dec 02, 2019 at 08:37:14PM +0000, Joseph Myers wrote:
> > On Mon, 2 Dec 2019, Segher Boessenkool wrote:
> > > Thanks for the list.  As far as I can see all of those are no longer
> > > useful, so they could be jut deleted from the SVN repo (if everyone
> > > else agrees!)  It is much safer to delete tags after the conversion to
> > > git, because that way it is much easier to get things back if something
> > > is lost after all, in general.
> >
> > One suggestion made in a comment on
> > <https://gitlab.com/esr/reposurgeon/issues/170> was making reposurgeon put
> > deleted tags and branches in refs/deleted/ so a converted version of the
> > data would be available without being fetched by default.  If that were
> > done, the data would be in git even for tags deleted before the
> > conversion.
>
> 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).
>
>
> Segher

Well that's true of /any/ renaming scheme for dead branches.  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.

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
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)
d) releases should go into refs/{heads/tags}/releases (makes it clearer 
to casual users of the repo that these are 'official')
e) other general development branches in refs/{heads/tags}/devt

That probably means the top-level heads/tags spaces are empty; but I 
have no problem with that.

R.