On Dec 3, 2019, at 11:10 PM, Richard Earnshaw (lists)
<richard.earns...@arm.com> wrote:
On 03/12/2019 18:56, Segher Boessenkool wrote:
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.
But you've still got the ongoing branch death issue to deal with, and
that was my point. If you want to keep them, and you don't want them
polluting the working namespace, you have to do *some* renaming of them.
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.
They can be found, it's just that they don't appear in the standard list
since they aren't pulled by default from the upstream repository. It's
no different from the situation where if you clone from a clone, the
things in the local repository that are in refs/remotes are not pulled
into the secondary clone, unless you add an explicit fetch entry to your
remote's configuration, something like
[origin]
...
fetch = refs/deleted/*:refs/remotes/origin/deleted/*
So they're not useless as you put it. They're out of the way, but can
be recovered if there's need. What's more, if the branch died without
being merged, the blobs for it will stay *on the server* and not waste
users' time and bandwidth by being repeatedly pulled.
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.
And see above for the type of fetch spec you'd need to pull and see them
locally, with the structure I suggest, you can even write
fetch = refs/vendors/ibm/heads/*:refs/remotes/origin/ibm/*
and only the ibm sub-part of that hierarchy would be fetched.
