This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Offer of help with move to git
- From: Jason Merrill <jason at redhat dot com>
- To: esr at thyrsus dot com
- Cc: Joseph Myers <joseph at codesourcery dot com>, gcc at gcc dot gnu dot org
- Date: Sat, 29 Aug 2015 00:43:36 -0400
- Subject: Re: Offer of help with move to git
- Authentication-results: sourceware.org; auth=none
- References: <20150823144340 dot GA7448 at thyrsus dot com> <alpine dot DEB dot 2 dot 10 dot 1508241350060 dot 19249 at digraph dot polyomino dot org dot uk> <20150824163157 dot GB23430 at thyrsus dot com> <alpine dot DEB dot 2 dot 10 dot 1508241640520 dot 19249 at digraph dot polyomino dot org dot uk> <55DFD188 dot 5060608 at redhat dot com> <20150828041313 dot GA22560 at thyrsus dot com>
On 08/28/2015 12:13 AM, Eric S. Raymond wrote:
With respect to Joseph's point about periodic deletion and re-creation of
branches, it looks like reposurgeon dutifully models them as deletion and
re-creation of the entire tree, which is understandable but not ideal. It
also warns about these with, e.g.,
reposurgeon: mid-branch deleteall on refs/heads/master at <184996>.
Looking over the instances of this warning, it seems that in most cases it
was branch maintainers deciding to blow away the entire branch and start
over because svn mergeinfo had gotten too confused. I think in all of these
cases the right thing is to pretend that the delete/recreate never happened.
Perhaps, but there be dragons here. Without those deletealls you could
easily end up with incorrect head-revision content. Before you try anything
clever here, examine the final repo state to see whther it looks like "the
delete/recreate never happened" - it very well might.
It looks like that for all the ones I've looked at, but I guess I can
look through all of them. I'm not sure how squashing the
delete/recreate together could change head content.
Unfortunately, it looks like reposurgeon doesn't deal with gcc SVN's
subdirectory branches any better than git-svn. It does give a diagnostic
about them:
reposurgeon: branch links detected by file ops only: branches/suse/
branches/apple/ branches/st/ branches/gcj/ branches/csl/ branches/google/
branches/linaro/ branches/redhat/ branches/ARM/ tags/ix86/ branches/ubuntu/
branches/ix86/
though this is an incomplete list. There are also also branches/ibm,
branches/dead, tags/apple, tags/redhat, tags/csl, and tags/ubuntu.
Ideally the conversion tool would just recognize that these are
subdirectories containing branches rather than branches themselves. Neither
git-svn nor reposurgeon currently do that, they both just treat them as one
big branch. This is easy enough to fix after the fact with git
filter-branch:
https://gcc.gnu.org/wiki/GitMirror#Subdirectory_branches
but you might want to improve reposurgeon to handle this pattern directly.
Look closely at branchify_map. I think we may be able to use it to get the
effect you want.
Aha, I hadn't noticed that yet. I'll give it a try, thanks.
Is 'jason' your preferred username everywhere? I'll set up write access
to the conversion-machinery repo for you if you like.
Yes, thanks.
Jason