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 jos...@codesourcery.com
