On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> 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?
In my current script (adjust-refs in the gcc-conversion repository;
limited testing done based on a GCC repository conversion from last week,
running a fresh conversion now with vendor tags kept for more testing),
I'm using refs/dead/heads for any branch that's not identified as a
release branch (those go in refs/heads/releases), is not identified as
associated with a vendor (those go in refs/vendors/<name>/heads), and has
not received any commits since the start of December 2017. The
development branches that have received commits since then end up in
refs/heads/devel:
refs/heads/devel/c++-coroutines
refs/heads/devel/c++-modules
refs/heads/devel/c++-name-lookup
refs/heads/devel/gccgo
refs/heads/devel/gfortran-caf
refs/heads/devel/gimple-linterchange
refs/heads/devel/gomp-5_0-branch
refs/heads/devel/ira-select
refs/heads/devel/range-gen3
refs/heads/devel/ranger
refs/heads/devel/ssa-range
refs/heads/devel/unified-autovect
Given the limited number of such active development branches, I suspect
most people developing on branches are doing so on git-only branches in
the git mirror because they find git much more convenient for working with
branches.
I've also added a script add-git-svn-history to the gcc-conversion
repository, that runs a single git fetch command to make the version of
history from the old mirror available in refs/git-old/ and
refs/git-svn-old/ (at a cost of making the repository about 0.3 GB bigger
on the server). My expectation for active git-only development branches
is that the branch maintainer will rebase a copy of the branch onto the
cleanly converted history and then put that rebased copy in
refs/heads/devel/, rather than continuing development on the branch in
refs/git-old/ based on the old version of the history.
(Note for people doing such rebasing: if the branch has had merges to it,
it's possible that rebasing might go most smoothly if done in two stages:
first rebase on top of the most recent commit, in the git-svn history,
from which you've merged, to get rid of the merge commits from the
history, then rebase on top of the corresponding commit in the new cleanly
converted history. It's best to avoid commits from the git-svn version of
the history ending up in the ancestry of active branches based on the
clean conversion of the history.)
> > > 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>.
My script also has some such tags g77-*, libf2c-* (it was necessary to
distinguish very similarly named tags such as g77-0_5_21 and g77_0_5_21,
where it appeared one tag contained gcc/f/ and the other contained
libf2c/), libgcj-*.
> For the branches, just gcc-9 - I don't see the point in having a redundant
> -branch on the name.
My script has a special case to use the name
refs/heads/releases/gcc-2.95.2.1-branch with "-branch" in there, because
there's also refs/tags/releases/gcc-2.95.2.1, and while technically git
allows you to have refs/heads/<name> and refs/tags/<name> both present,
it's a bad idea to do so because "git checkout releases/gcc-2.95.2.1"
would be confusing if you expected it to check out one of the tag and the
branch and git chose to check out the other. (Other such ambiguities are
dealt with by putting ".0" on the names of some tags.)
> > 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
For now my script is using refs/tags/prereleases/ (keeping existing choice
of "pre", "prerelease", "rc", "test" naming rather than making that more
uniform; refs/tags/prereleases/egcs-1.1.1-pre and
refs/tags/prereleases/egcs-1.1.1-prerelease are two different tags).
> > 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.
My script is checked into the gcc-conversion repository, but the only
dependency on other machinery in there is that it reads gcc.opts to work
out the mapping between SVN and git branch names.
My script, by design, *only* renames refs (and prints out the mapping from
SVN to git ref names, and information about branches that were only found
in SVN, which could be used in validation of the resulting repository).
That is, it makes no changes at all to the commit graph (that's left for
the reposurgeon lift script). (While the script add-git-svn-history
*only* adds in the version of history from the git mirror with its own
commit graph disconnected from that from a fresh conversion, without
making any changes to the freshly converted history.)
Note that my script to rename refs is not idempotent. So if experimenting
with it, you want to copy your converted repository and run it on a copy,
using a fresh copy for each run of the script.
--
Joseph S. Myers
jos...@codesourcery.com
