Re: Branch and tag deletions

[Richard Earnshaw (lists)]

On 03/12/2019 00:56, Segher Boessenkool wrote:

On Mon, Dec 02, 2019 at 08:37:14PM +, Joseph Myers wrote:

On Mon, 2 Dec 2019, Segher Boessenkool wrote:

Thanks for the list.  As far as I can see all of those are no longer
useful, so they could be jut deleted from the SVN repo (if everyone
else agrees!)  It is much safer to delete tags after the conversion to
git, because that way it is much easier to get things back if something
is lost after all, in general.


One suggestion made in a comment on
 was making reposurgeon put
deleted tags and branches in refs/deleted/ so a converted version of the
data would be available without being fetched by default.  If that were
done, the data would be in git even for tags deleted before the
conversion.


That sounds simpler than it is...  After using this for a while you'll
get names that you want to delete, but that name *already* is in
/refs/deleted.  So what will you name it then?  People will still need
to be able to find it.

But we could make an "old-svn" hierarchy or similar that just has
everything svn has now (and will never change, so it will never cause
conflicts).


Segher



Well that's true of /any/ renaming scheme for dead branches.  There's 
nothing special about this one.  On the other hand, there's nothing that 
says that the renamed branch has to have exactly the same name as the 
live one: it's a rename after all.


You only have to run 'svn ls' on the current gcc branches directory in 
SVN to realize just what a mess our current naming scheme it, so I'd 
also suggest that we do some general reorganization of the other 
branches/tags we have, especially if we have a /refs/svn namespace after 
conversion:


a) Only live development branches get moved to the normal git namespace, 
but see d) & e) below
b) vendor branches should move to something like 
refs/vendors//{heads/tags} (these won't be pulled by default by 
a normal clone, you'd have to add an explicit map request to see them.
c) user branches should only be in something line 
refs/users//{heads/tags} (similar to above)
d) releases should go into refs/{heads/tags}/releases (makes it clearer 
to casual users of the repo that these are 'official')

e) other general development branches in refs/{heads/tags}/devt

That probably means the top-level heads/tags spaces are empty; but I 
have no problem with that.


R.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 03/12/2019 00:47, Segher Boessenkool wrote:

On Mon, Dec 02, 2019 at 08:24:47PM +, Joseph Myers wrote:

On Mon, 2 Dec 2019, Segher Boessenkool wrote:


Sure; I'm just saying rewriting old commit messages in such a style that
they keep standing out from new ones is a bit of a weird choice.


I'd say the rewrites make them stand out *less* (if people avoid having
new commit messages whose summary line is just the ChangeLog header line).


New commits will not start with [smth] in general.  Of course you *can*
do that, with enough effort.  You can also have two consecutive empty
lines in your commit messages just fine, but git won't let you without
a fight.  This is similar.


Simply having the Legacy-ID in the commit message will be a visible
difference from new commit messages.  But I'm happy it's desirable to have
it there, because references to SVN revisions in list archives are so
common and having it in the commit messages makes it very quick and easy
to map to a git commit id, without needing any on-the-side lists of commit
mappings or other tools.


Yes.  Either in the subject line, or later in the commit message (as
with git-svn).  We can quibble about where is best, but (hopefully)
everyone agrees we need the SVN id *somewhere* :-)


Segher



With my trial reposurgeon conversion:

git log --all --oneline --grep="Legacy-ID: $"

-all searches all branches, the trailing $ ensures an exact match; 
--oneline just prints the short summary.


eg.
$ git log --oneline --all --grep="Legacy-ID: 278572$"
44e365ba66c [backport] quadmath.h (M_Eq, [...]): Use two more decimal 
places.


No need to put this in the summary.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 03/12/2019 09:44, Richard Earnshaw (lists) wrote:

On 03/12/2019 00:47, Segher Boessenkool wrote:

On Mon, Dec 02, 2019 at 08:24:47PM +, Joseph Myers wrote:

On Mon, 2 Dec 2019, Segher Boessenkool wrote:

Sure; I'm just saying rewriting old commit messages in such a style 
that

they keep standing out from new ones is a bit of a weird choice.


I'd say the rewrites make them stand out *less* (if people avoid having
new commit messages whose summary line is just the ChangeLog header 
line).


New commits will not start with [smth] in general.  Of course you *can*
do that, with enough effort.  You can also have two consecutive empty
lines in your commit messages just fine, but git won't let you without
a fight.  This is similar.


Simply having the Legacy-ID in the commit message will be a visible
difference from new commit messages.  But I'm happy it's desirable to 
have

it there, because references to SVN revisions in list archives are so
common and having it in the commit messages makes it very quick and easy
to map to a git commit id, without needing any on-the-side lists of 
commit

mappings or other tools.


Yes.  Either in the subject line, or later in the commit message (as
with git-svn).  We can quibble about where is best, but (hopefully)
everyone agrees we need the SVN id *somewhere* :-)


Segher



With my trial reposurgeon conversion:

 git log --all --oneline --grep="Legacy-ID: $"

-all searches all branches, the trailing $ ensures an exact match; 
--oneline just prints the short summary.


eg.
$ git log --oneline --all --grep="Legacy-ID: 278572$"
44e365ba66c [backport] quadmath.h (M_Eq, [...]): Use two more decimal 
places.


No need to put this in the summary.


Or even:

git config alias.svn-rev '!f() { rev=$1; shift; git log --all --oneline 
--grep="Legacy-ID: $rev$" ${@}; } ; f'


now you can do

$ git svn-rev 278572 --oneline
44e365ba66c [backport] quadmath.h (M_Eq, [...]): Use two more decimal 
places.


or

$ git svn-rev 278572
commit 44e365ba66c6ccf6cb05f75771946d2992bd51c4
Author: Jakub Jelinek 
Date:   Thu Nov 21 18:07:15 2019 +0100

[backport] quadmath.h (M_Eq, [...]): Use two more decimal places.

Backported from mainline
2019-08-02  Jakub Jelinek  

* quadmath.h (M_Eq, M_LOG2Eq, M_LOG10Eq, M_LN2q, M_LN10q, 
M_PIq,

M_PI_2q, M_PI_4q, M_1_PIq, M_2_PIq, M_2_SQRTPIq, M_SQRT2q,
M_SQRT1_2q): Use two more decimal places.

Legacy-ID: 278572

R.

Re: Branch and tag deletions

[Joseph Myers]

On Mon, 2 Dec 2019, Segher Boessenkool wrote:

> On Fri, Nov 29, 2019 at 10:31:22PM +, Joseph Myers wrote:
> > On Fri, 29 Nov 2019, Segher Boessenkool wrote:
> > > Please post the full names of all the tags you want to delete?
> > 
> > Here is a list of 645 tags proposed for removal, in the various
> > categories I gave.  Vendor tags are only included where they also fall
> > into one of the other categories (e.g. tags that appear to be purely
> > for merge tracking and so would not idiomatically exist in git at
> > all).
> 
> [ snip ]
> 
> Thanks for the list.  As far as I can see all of those are no longer
> useful, so they could be jut deleted from the SVN repo (if everyone
> else agrees!)

Thanks.  Do other people have comments on the list?

I'm going to add one vendor tag that should be uncontroversial to the 
list.  /tags/gcc-1766 is a misnamed Apple tag, and there is already a 
properly named copy with identical contents at /tags/apple/gcc-1766 so 
deleting /tags/gcc-1766 should be safe.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Branch and tag deletions

[Joseph Myers]

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.)

> 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?

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".

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.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Branch and tag deletions

[Richard Earnshaw (lists)]

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?





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-.


For the branches, just gcc-9 - I don't see the point in having a 
redundant -branch on the name.




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




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.


R.

Re: Branch and tag deletions

[Richard Earnshaw (lists)]

On 03/12/2019 13:26, Joseph Myers wrote:

On Mon, 2 Dec 2019, Segher Boessenkool wrote:


On Fri, Nov 29, 2019 at 10:31:22PM +, Joseph Myers wrote:

On Fri, 29 Nov 2019, Segher Boessenkool wrote:

Please post the full names of all the tags you want to delete?


Here is a list of 645 tags proposed for removal, in the various
categories I gave.  Vendor tags are only included where they also fall
into one of the other categories (e.g. tags that appear to be purely
for merge tracking and so would not idiomatically exist in git at
all).


[ snip ]

Thanks for the list.  As far as I can see all of those are no longer
useful, so they could be jut deleted from the SVN repo (if everyone
else agrees!)


Thanks.  Do other people have comments on the list?

I'm going to add one vendor tag that should be uncontroversial to the
list.  /tags/gcc-1766 is a misnamed Apple tag, and there is already a
properly named copy with identical contents at /tags/apple/gcc-1766 so
deleting /tags/gcc-1766 should be safe.



I've looked through the list; I don't see anything that looks like it 
would be especially controversial.


R.

Re: Branch and tag deletions

[Segher Boessenkool]

On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
> On 03/12/2019 00:56, Segher Boessenkool wrote:
> >That sounds simpler than it is...  After using this for a while you'll
> >get names that you want to delete, but that name *already* is in
> >/refs/deleted.  So what will you name it then?  People will still need
> >to be able to find it.
> >
> >But we could make an "old-svn" hierarchy or similar that just has
> >everything svn has now (and will never change, so it will never cause
> >conflicts).
> 
> Well that's true of /any/ renaming scheme for dead branches.

No, it is not.  If you have a simple "deleted" hierarchy, to which you
add things, you will get conflicts.  If you have one just for things
imported from SVN, it will never change (since SVN is set in stone after
the conversion), and there will not be conflicts.

> There's 
> nothing special about this one.  On the other hand, there's nothing that 
> says that the renamed branch has to have exactly the same name as the 
> live one: it's a rename after all.

Renamed tags and branches are *useless*, we could just as well delete
them completely, if people can no longer find them.

> You only have to run 'svn ls' on the current gcc branches directory in 
> SVN to realize just what a mess our current naming scheme it, so I'd 
> also suggest that we do some general reorganization of the other 
> branches/tags we have, especially if we have a /refs/svn namespace after 
> conversion:
> 
> a) Only live development branches get moved to the normal git namespace, 
> but see d) & e) below

Yes, I called it "old-svn" for a reason.  One idea is to move *everything*
there, and let people make a copy to the "live" stuff if they want it.
And we can pre-populate the things we know are still used, of course, and
all release branches (closed or not), that kind of thing.  But we could
just shovel all that is in SVN into some nice tidy subdir, that normal
people never have to look at again :-)

> b) vendor branches should move to something like 
> refs/vendors//{heads/tags} (these won't be pulled by default by 
> a normal clone, you'd have to add an explicit map request to see them.
> c) user branches should only be in something line 
> refs/users//{heads/tags} (similar to above)

Yup.

> d) releases should go into refs/{heads/tags}/releases (makes it clearer 
> to casual users of the repo that these are 'official')

What are releases?  Release branches?

It would be very inconvenient to not have the recent releases immediately
accessible, fwiw, but those could be just a copy.  And then delete that
one after a branch is closed?

> e) other general development branches in refs/{heads/tags}/devt

What does this mean?  "other", "general"?

> That probably means the top-level heads/tags spaces are empty; but I 
> have no problem with that.

It is good when people get the most often used things immediately.


Segher

Re: Branch and tag deletions

[Richard Earnshaw (lists)]

On 03/12/2019 18:56, Segher Boessenkool wrote:
> On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
>> On 03/12/2019 00:56, Segher Boessenkool wrote:
>>> That sounds simpler than it is...  After using this for a while you'll
>>> get names that you want to delete, but that name *already* is in
>>> /refs/deleted.  So what will you name it then?  People will still need
>>> to be able to find it.
>>>
>>> But we could make an "old-svn" hierarchy or similar that just has
>>> everything svn has now (and will never change, so it will never cause
>>> conflicts).
>>
>> Well that's true of /any/ renaming scheme for dead branches.
> 
> No, it is not.  If you have a simple "deleted" hierarchy, to which you
> add things, you will get conflicts.  If you have one just for things
> imported from SVN, it will never change (since SVN is set in stone after
> the conversion), and there will not be conflicts.

But you've still got the ongoing branch death issue to deal with, and
that was my point.  If you want to keep them, and you don't want them
polluting the working namespace, you have to do *some* renaming of them.


> 
>> There's 
>> nothing special about this one.  On the other hand, there's nothing that 
>> says that the renamed branch has to have exactly the same name as the 
>> live one: it's a rename after all.
> 
> Renamed tags and branches are *useless*, we could just as well delete
> them completely, if people can no longer find them.

They can be found, it's just that they don't appear in the standard list
since they aren't pulled by default from the upstream repository.  It's
no different from the situation where if you clone from a clone, the
things in the local repository that are in refs/remotes are not pulled
into the secondary clone, unless you add an explicit fetch entry to your
remote's configuration, something like

[origin]
...
fetch = refs/deleted/*:refs/remotes/origin/deleted/*


So they're not useless as you put it.  They're out of the way, but can
be recovered if there's need.  What's more, if the branch died without
being merged, the blobs for it will stay *on the server* and not waste
users' time and bandwidth by being repeatedly pulled.

> 
>> You only have to run 'svn ls' on the current gcc branches directory in 
>> SVN to realize just what a mess our current naming scheme it, so I'd 
>> also suggest that we do some general reorganization of the other 
>> branches/tags we have, especially if we have a /refs/svn namespace after 
>> conversion:
>>
>> a) Only live development branches get moved to the normal git namespace, 
>> but see d) & e) below
> 
> Yes, I called it "old-svn" for a reason.  One idea is to move *everything*
> there, and let people make a copy to the "live" stuff if they want it.
> And we can pre-populate the things we know are still used, of course, and
> all release branches (closed or not), that kind of thing.  But we could
> just shovel all that is in SVN into some nice tidy subdir, that normal
> people never have to look at again :-)
> 
>> b) vendor branches should move to something like 
>> refs/vendors//{heads/tags} (these won't be pulled by default by 
>> a normal clone, you'd have to add an explicit map request to see them.
>> c) user branches should only be in something line 
>> refs/users//{heads/tags} (similar to above)
> 
> Yup.

And see above for the type of fetch spec you'd need to pull and see them
locally, with the structure I suggest, you can even write

fetch = refs/vendors/ibm/heads/*:refs/remotes/origin/ibm/*

and only the ibm sub-part of that hierarchy would be fetched.

> 
>> d) releases should go into refs/{heads/tags}/releases (makes it clearer 
>> to casual users of the repo that these are 'official')
> 
> What are releases?  Release branches?

branches in the heads space, tags in the tags space.

> 
> It would be very inconvenient to not have the recent releases immediately
> accessible, fwiw, but those could be just a copy.  And then delete that
> one after a branch is closed?
> 
>> e) other general development branches in refs/{heads/tags}/devt
> 
> What does this mean?  "other", "general"?

Anything that's not vendor/user specific and not a release - a topic
branch most likely
> 
>> That probably means the top-level heads/tags spaces are empty; but I 
>> have no problem with that.
> 
> It is good when people get the most often used things immediately.

git branch -a will show anything in refs/remotes, and the default pull
spec is to pull refs/heads/* (and anything under that), so all release
and topic branches would be pulled by default, but not anything else.

According to the git fetch manual page, tags are fetched if an object
they point to is fetched.  I presume this only applies to tags under
refs/tags.  But this is getting into details of git that I've not used
before.  I need to experiment a bit more here.

R.

PS.  Just seen https://git-scm.com/docs/gitnamespaces, that might be
exactly what we want for us

Re: Branch and tag deletions

[Segher Boessenkool]

On Tue, Dec 03, 2019 at 08:10:37PM +, Richard Earnshaw (lists) wrote:
> On 03/12/2019 18:56, Segher Boessenkool wrote:
> > On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
> >>> But we could make an "old-svn" hierarchy or similar that just has
> >>> everything svn has now (and will never change, so it will never cause
> >>> conflicts).
> >>
> >> Well that's true of /any/ renaming scheme for dead branches.
> > 
> > No, it is not.  If you have a simple "deleted" hierarchy, to which you
> > add things, you will get conflicts.  If you have one just for things
> > imported from SVN, it will never change (since SVN is set in stone after
> > the conversion), and there will not be conflicts.
> 
> But you've still got the ongoing branch death issue to deal with, and
> that was my point.  If you want to keep them, and you don't want them
> polluting the working namespace, you have to do *some* renaming of them.

Sure, but how many of those will there be?  This is a different scale
problem from that with the SVN branches and tags, which makes it a quite
different problem.

> >> There's 
> >> nothing special about this one.  On the other hand, there's nothing that 
> >> says that the renamed branch has to have exactly the same name as the 
> >> live one: it's a rename after all.
> > 
> > Renamed tags and branches are *useless*, we could just as well delete
> > them completely, if people can no longer find them.
> 
> They can be found, it's just that they don't appear in the standard list
> since they aren't pulled by default from the upstream repository.  It's
> no different from the situation where if you clone from a clone, the
> things in the local repository that are in refs/remotes are not pulled
> into the secondary clone, unless you add an explicit fetch entry to your
> remote's configuration, something like
> 
> [origin]
> ...
>   fetch = refs/deleted/*:refs/remotes/origin/deleted/*

No.  If you rename a branch, you have to look at all thousands of branches
to see which one might be the one you wanted.  Something with a similar
name hopefully?

I'm not saying things moved into some separate hierarchy.  That is fine.
But that *will* give conflicts if you keep doing that on a live repo,
and then you *do* need real renames.

And you then cannot refer to things by name anymore.  Which is the common
way we refer to anything.

> >> d) releases should go into refs/{heads/tags}/releases (makes it clearer 
> >> to casual users of the repo that these are 'official')
> > 
> > What are releases?  Release branches?
> 
> branches in the heads space, tags in the tags space.

Release branches and releases are a very different thing.  A release
is some fixed source, like a tarball.  A release branch is a branch, and
what code that is can (and will, and does) change.

Not that I have good suggestions how to make this less confusing.  Well,
maybe we should keep calling it "gcc-9-branch" and "gcc-9_2_0-release"?

To make it clear that these are "official" the release tags should be
signed with an "official" key, of course ;-)

> > It would be very inconvenient to not have the recent releases immediately
> > accessible, fwiw, but those could be just a copy.  And then delete that
> > one after a branch is closed?
> > 
> >> e) other general development branches in refs/{heads/tags}/devt
> > 
> > What does this mean?  "other", "general"?
> 
> Anything that's not vendor/user specific and not a release - a topic
> branch most likely

Should we often have those?  We can just use user branches for this?

We *want* to rebase etc. on topic branches: allow non-fast-forwards.
And that is *very* problematic if multiple people can write to that
branch.


Segher

LTO : question about get_untransformed_body

[Erick Ochoa]

Hi,

I am trying to use the function: `cgraph_node::get_untransformed_body` during
the wpa stage of a SIMPLE_IPA_PASS transformation. While the execute function
is running, I need to access the body of a function in order to iterate over
the gimple instructions in the first basic block. I have found that the
majority of the cgraph_node will return successfully. However, there are some
functions which consistently produce a segmentation fault following this
stacktrace:

```
0xbc2adb crash_signal
/home/eochoa/code/gcc/gcc/toplev.c:328
0xa54858 lto_get_decl_name_mapping(lto_file_decl_data*, char const*)
/home/eochoa/code/gcc/gcc/lto-section-in.c:367
0x7030e7 cgraph_node::get_untransformed_body()
/home/eochoa/code/gcc/gcc/cgraph.c:3516
0x150613f get_bb1_callees
/home/eochoa/code/gcc/gcc/ipa-initcall-cp.c:737
0x150613f reach_nodes_via_bb1_dfs
```

Is there a way for `cgraph_node::get_untransformed_body` to succeed
consistently? (I.e. are there some preconditions that I need to make sure are
in place before calling cgraph_node::get_untransformed_body?

I am using gcc version 10.0.0 20191127 (experimental)

Thanks

Default "others" value for designated array initializers

[Yonatan Goldschmidt]

Hello GCC community,

Designated initializers can be used in arrays to initialize by index:

int a[6] = { [4] = 29, [2] = 15 }

and by range:

int a[6] = { [2 ... 4] = 5 }

but it seems there's no syntax to initialize all the "others" of the elements, 
i.e those not
specified by any initializer.

After a bit of playing around, I found that you can override previous 
initializers. So
it allows to make defaults this way:

int a[6] = { [0 ... 5] = -1, [2 ... 4] = 5, [5] = 15 }

However, I find this method very error prone. Designated initializers, in my 
opinion, are supposed
to allow me to disregard the initialization order, because I have field names 
for structs/unions,
and indices for arrays, thus the order doesn't matter.
But when I use this trick, it requires me to mind this very first line, 
otherwise my array will
go terribly wrong.

Any reason GCC doesn't have a special syntax for this case?
I couldn't find anything about it online / in this list.

Thanks,

Yonatan

Re: Branch and tag deletions

[Joseph Myers]

On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:

> > 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.

OK, I'm working on that (and have moving of vendor branches working).

Eric, can Richard and I get direct write access to the gcc-conversion 
repository?  Waiting for merge requests to be merged is getting in the way 
of fast iteration on incremental improvements to the conversion machinery, 
it should be possible to get multiple incremental improvements a day into 
the repository.

-- 
Joseph S. Myers
jos...@codesourcery.com