Re: Repository for the conversion machinery

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 6 Oct 2016, Jason Merrill wrote:

> After I ran into a couple of reposurgeon bugs and didn't hear back
> from you, I started investigating rewriting the existing git svn
> mirror with git filter-branch instead.  That seems an attractive
> option, but not long afterward I needed to shift focus to front end

I've used both git-svn (sometimes with git filter-branch) and reposurgeon 
for repository conversions.  My experience is that if there's anything at 
all complicated or messy about the history, using git-svn for the 
conversion is not a good idea, so I don't think that's an attractive 
option at all.  (The non-rewritten git-svn history can be kept alongside 
the reposurgeon conversion using the git fetch command I gave in 
<https://gcc.gnu.org/ml/gcc/2015-09/msg00040.html>, so existing commit 
references remain meaningful.)

> We should also reopen discussion of workflow and branch policies.  One

There's very little there that should be done before the conversion.  We 
only need enough policy to set up hooks and repository configuration.  A 
starting point would be no non-fast-forward ref updates, either no ref 
deletions or ref deletions restricted to some defined namespace for user 
branches, commit mails to gcc-cvs continue as at present (showing the 
commit message and list of changed files, but not the full diffs), other 
hook actions such as Bugzilla updates continue as at present, all commit 
policies continue as at present.  I think people should be encouraged to 
write git-style commit messages with a meaningful summary line followed by 
something like the description in a mailing list posting of a patch, but I 
think that's a good idea independent of the conversion.

> concern I have about the git conversion is that gcc.gnu.org already
> refuses git connections fairly frequently due to overloading, and I'm
> afraid that will become much more common when current SVN users switch
> over.

That's for anonymous connections, not for git over ssh; I don't think it 
should block the conversion.  I think it's been a while since the hardware 
was refreshed, maybe it's time for work on new hardware (with or without 
an OS update to RHEL 7) to start?  (The more cores the hardware has, the 
higher the load threshold for refusing connections can be.)

-- 
Joseph S. Myers
joseph@codesourcery.com