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.
