This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Branch and tag deletions
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>, Richard Biener <richard dot guenther at gmail dot com>, "Eric S. Raymond" <esr at thyrsus dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 2 Dec 2019 18:56:00 -0600
- Subject: Re: Branch and tag deletions
- References: <20191128034449.GA84526@thyrsus.com> <alpine.DEB.2.21.1911281630370.32289@digraph.polyomino.org.uk> <CAFiYyc3XV14yUVdjLNTAAog08Ea18wMV29Z9gzvADyGscvDojg@mail.gmail.com> <alpine.DEB.2.21.1911291609110.21906@digraph.polyomino.org.uk> <7473e40e-fa2c-1561-c987-c402f9582701@arm.com> <alpine.DEB.2.21.1911291656100.21906@digraph.polyomino.org.uk> <20191129220331.GS9491@gate.crashing.org> <alpine.DEB.2.21.1911292221220.31650@digraph.polyomino.org.uk> <20191202174459.GE24609@gate.crashing.org> <alpine.DEB.2.21.1912022025131.23075@digraph.polyomino.org.uk>
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