Re: Test GCC conversion with reposurgeon available

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 9 Jan 2020, Joseph Myers wrote:

> Here's a test conversion with the conversion machinery in what should be 
> essentially final form.  This is like the "b" versions (dead and vendor 
> branches present but not fetched by default), with the addition of refs 
> from the existing git mirror as refs/git-old/* and refs/git-svn-old/* (not 
> fetched by default).
> 
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git

Hooks are now set up and ready for testing commits to this repository, 
including integration with gcc-cvs and libstdc++-cvs mailing lists and 
Bugzilla.  I recommend only referencing test bugs you open for the purpose 
in commits, not real bugs, to avoid confusing people, as the messages that 
end up in Bugzilla don't make it obvious that this is a test conversion 
(the messages on the -cvs mailing lists are more obvious, as they say 
"gcc-reposurgeon-8" in their subject headers).  Commits made in this 
repository will not end up in the real conversion.  gitweb URLs in 
messages from this conversion won't actually work, because they point to 
the real gitweb (which currently points to the git-svn mirror).

All commits should generate commit emails.  Only commits to master and 
release branches should generate Bugzilla updates.  master and release 
branches do not allow merge commits, other branches do.  Branches in 
refs/users/<user>/heads and refs/vendors/<vendor>/heads allow 
non-fast-forward pushes and branch deletion, other branches don't.

Branch updates or new branches based on the history from the git-svn 
mirror (with 3cf0d8938a953ef13e57239613d42686f152b4fe, the initial git-svn 
commit, in their ancestry) are disallowed; this avoids someone 
accidentally pushing such a branch to a namespace that git fetches by 
default and causing everyone to fetch a GB of extra history as a result.  
Thus, for continued development based on such a branch you should start by 
rebasing (not merging) onto the new version of the history, and then the 
rebased branch can be pushed to one of the supported namespaces (under 
refs/users/<user>/heads/ if treating it as a user branch, under 
refs/heads/devel/ for a development branch that gets fetched by default).

The hook configuration is something that seemed reasonable as a starting 
point, not necessarily what we will have as the final configuration.  The 
configuration file for the AdaCore hooks is project.config on the 
refs/meta/config branch (but there are local patches to those hooks at 
present, and as with other refs, changes to refs/meta/config will not 
persist to the final converted repository).

-- 
Joseph S. Myers
joseph@codesourcery.com