This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Branch and tag deletions

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
<> 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

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]