On 03/12/2019 15:05, Joseph Myers wrote:
On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
a) Only live development branches get moved to the normal git namespace, but
see d) & e) below
Where do you suggest dead development branches should go? (We have
/branches/dead at present in SVN but hardly anything there; most dead
development branches are just in /branches.)
Well, like 'deleted', we could move them out of the normally synced
namespace; I don't have a strong preference, however, so what would you
propose?
d) releases should go into refs/{heads/tags}/releases (makes it clearer to
casual users of the repo that these are 'official')
Do you have a particular naming suggestion in there, e.g.
refs/heads/releases/9 and refs/tags/releases/9.1 (with the ".0" included
in tag names for old releases to avoid conflict with the branch name), or
with "gcc" or "branch" etc. in names as at present?
I think I'd drop 'release' and use something like releases/gcc-9.1, then
for the historical egcs releases egcs-<version>.
For the branches, just gcc-9 - I don't see the point in having a
redundant -branch on the name.
Some of the tags I did not propose deleting are tags for past prereleases
(we shouldn't need such tags for new -rc versions because a git commit id
suffices to identify them) and need an appropriate place in git, which
could also be in refs/tags/releases. Some are for releases or prereleases
of subprojects that had such releases on their own (e.g. g77, libgcj,
libstdc++). We need to establish where those would go in git. There are
also a few miscellaneous tags such as "start" and "first-egcs-checkin".
We could have another space for rc's alphas, etc, refs/heads/rc would
work as well as any
I can work on a script to do such rearrangements of tags and branches in
the repository. My inclination is that such rearrangements of tag and
branch names are probably done in a separate postprocessing script rather
than as part of the conversion itself, especially if we're using custom
namespaces not in refs/heads/ and refs/tags/ - this makes verifying the
conversion simpler. (But deletions of tags and branches we don't want to
convert at all are appropriate to do in SVN.)
That would be great. It would probably also be faster than the
reposurgeon approach, and it would also work with the other candidate
conversions we still have on the table.
R.
