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.
>
>> d) releases should go into refs/{heads/tags}/releases (makes it clearer
>> to casual users of the repo that these are 'official')
>
> What are releases? Release branches?
branches in the heads space, tags in the tags space.
>
> It would be very inconvenient to not have the recent releases immediately
> accessible, fwiw, but those could be just a copy. And then delete that
> one after a branch is closed?
>
>> e) other general development branches in refs/{heads/tags}/devt
>
> What does this mean? "other", "general"?
Anything that's not vendor/user specific and not a release - a topic
branch most likely
>
>> That probably means the top-level heads/tags spaces are empty; but I
>> have no problem with that.
>
> It is good when people get the most often used things immediately.
git branch -a will show anything in refs/remotes, and the default pull
spec is to pull refs/heads/* (and anything under that), so all release
and topic branches would be pulled by default, but not anything else.
According to the git fetch manual page, tags are fetched if an object
they point to is fetched. I presume this only applies to tags under
refs/tags. But this is getting into details of git that I've not used
before. I need to experiment a bit more here.
R.
PS. Just seen https://git-scm.com/docs/gitnamespaces, that might be
exactly what we want for users, vendors and legacy stuff. I'll
investigate some more...
