On Thu, Dec 05, 2019 at 11:55:12AM +0300, Maxim Kuvyrkov wrote:
> > On Dec 3, 2019, at 11:10 PM, Richard Earnshaw (lists)
> > wrote:
> > 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
On Wed, Dec 04, 2019 at 09:53:31AM +, Richard Earnshaw (lists) wrote:
> On 03/12/2019 22:43, Segher Boessenkool wrote:
> >>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 na
Joseph Myers :
> The avoidance of '.' in branch and tag names is, I'm pretty sure, a legacy
> of CVS restrictions on valid names for branches and tags. Those
> restrictions are not relevant to git or SVN; if picking any new convention
> it seems appropriate for the tag for GCC 10.1 to say "10.1
On 05/12/2019 08:55, Maxim Kuvyrkov wrote:
On Dec 3, 2019, at 11:10 PM, 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:
On 03/12/2019 00:56, Segher Boessenkool wrote:
That sounds simpler
> On Dec 3, 2019, at 11:10 PM, 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:
>>> On 03/12/2019 00:56, Segher Boessenkool wrote:
That sounds simpler than it is... After using
Here is a very preliminary list of refs after postprocessing by my script,
to indicate what the ref layout would look like. We can easily change the
script if we'd like some other layout. Note that some refs here will go
away after deleting corresponding tags in SVN, while others are missing
On Wed, Dec 04, 2019 at 08:37:17PM +, Joseph Myers wrote:
> On Wed, 4 Dec 2019, Segher Boessenkool wrote:
> > And, as I said before, a release branch is a totally different animal
> > from releases (release tags). We do this correctly now, let's keep it
> > that way?
>
> By convention, a bran
On Wed, 4 Dec 2019, Segher Boessenkool wrote:
> > My script has a special case to use the name
> > refs/heads/releases/gcc-2.95.2.1-branch with "-branch" in there, because
> > there's also refs/tags/releases/gcc-2.95.2.1, and while technically git
> > allows you to have refs/heads/ and refs/tag
On Wed, Dec 04, 2019 at 06:25:21PM +, Joseph Myers wrote:
> In my current script (adjust-refs in the gcc-conversion repository;
> limited testing done based on a GCC repository conversion from last week,
> running a fresh conversion now with vendor tags kept for more testing),
> I'm using re
On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> 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
On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> > 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 identica
On Wed, 4 Dec 2019, Eric S. Raymond wrote:
> Joseph Myers :
> > 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,
> >
Joseph Myers :
> 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 imp
On 03/12/2019 22:43, Segher Boessenkool wrote:
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
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
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 n
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 nam
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 yo
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 propo
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
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
develo
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 var
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
els
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 delet
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 var
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
Joseph Myers :
> I did a comparison of git and SVN checkouts to look at missing file
> problems. I've now filed reposurgeon issues 171 and 172 for the problems
> I noted. Issue 171 relates to handling of trunk deletion / recreation.
> Issue 172 relates to the first point where missing file pr
On Wed, 27 Nov 2019, Eric S. Raymond wrote:
> Joseph Myers :
> > > I'm more worried about missing files. I saw a bunch of those on my
> > > last test. This could be spurious - the elaborate set of branch
> > > mappings you specified confuses my validation test, because there is
> > > no longer a
On Fri, 29 Nov 2019, Segher Boessenkool wrote:
> On Fri, Nov 29, 2019 at 04:57:30PM +, Joseph Myers wrote:
> > On Fri, 29 Nov 2019, Richard Earnshaw (lists) wrote:
> >
> > > I'm not convinced these should be just deleted. At least, not without the
> > > specific vendor's agreement. But perh
On Fri, Nov 29, 2019 at 04:57:30PM +, Joseph Myers wrote:
> On Fri, 29 Nov 2019, Richard Earnshaw (lists) wrote:
>
> > I'm not convinced these should be just deleted. At least, not without the
> > specific vendor's agreement. But perhaps they should not be in the default
> > refs/tags namesp
On Fri, 29 Nov 2019, Richard Earnshaw (lists) wrote:
> I'm not convinced these should be just deleted. At least, not without the
> specific vendor's agreement. But perhaps they should not be in the default
> refs/tags namespace.
What about the other tags I listed? Can we get agreement on delet
On 29/11/2019 16:14, Joseph Myers wrote:
# Tags for vendor releases.
tag/ARM/ delete
tag/apple/gcc/ delete
tag/csl/ delete
tag /linaro-/ delete
tag /microblaze-/ delete
tag/st/GCC/ delete
tag /ubuntu/gcc-/ delete
tag egcs_1_0_x_redhat5_1 delete
tag gcc-1766 delete
tag gcc-3_2-rhl8-3_2-7 delet
On Fri, 29 Nov 2019, Richard Biener wrote:
> Can't branches and tags be deleted after the conversion as well?
Yes (manually on the server, depending on the exact configuration we set
up for what pushes are allowed), but deleting before conversion speeds up
the process of verifying conversion co
On Thu, Nov 28, 2019 at 5:46 PM Joseph Myers wrote:
>
> On Wed, 27 Nov 2019, Eric S. Raymond wrote:
>
> > Joseph Myers :
> > > One more observation on that: in my last test conversion, deleting the
> > > emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the
> > > conversion was s
On Wed, 27 Nov 2019, Eric S. Raymond wrote:
> Joseph Myers :
> > One more observation on that: in my last test conversion, deleting the
> > emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the
> > conversion was spent just deleting those tags). Deleting tags matching
> > /-r
Joseph Myers :
> One more observation on that: in my last test conversion, deleting the
> emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the
> conversion was spent just deleting those tags). Deleting tags matching
> /-root$/ took about half an hour. So I think there is a p
On Tue, 26 Nov 2019, Eric S. Raymond wrote:
> Joseph Myers :
> > A further note: in a previous run of the conversion I didn't see any
> > emptycommit-* tags. In my most recent conversion run, I see 4070 such
> > tags. How do I tell reposurgeon never to create such tags? Or should I
> > add a
Joseph Myers :
> > I'm more worried about missing files. I saw a bunch of those on my
> > last test. This could be spurious - the elaborate set of branch
> > mappings you specified confuses my validation test, because there is
> > no longer a 1-1 corresponsence between Subversion and git branches.
On Wed, 27 Nov 2019, Eric S. Raymond wrote:
> Joseph Myers :
> > My current test conversion run is testing two changes: deleting
> > emptycommit tags, and using --user-ignores to prefer the .gitignore file
> > in SVN over one auto-generated from svn:ignore properties. For the next
> > one afte
Joseph Myers :
> My current test conversion run is testing two changes: deleting
> emptycommit tags, and using --user-ignores to prefer the .gitignore file
> in SVN over one auto-generated from svn:ignore properties. For the next
> one after that I'll try eliminating all branch/tag removals tha
On Wed, 27 Nov 2019, Eric S. Raymond wrote:
> > Sure, we could do that. Eric, can you confirm that, with current
> > reposurgeon, if a branch or tag was deleted in SVN and does not appear in
> > the final revision of /branches or /tags, it should not appear in the
> > resulting converted repos
Joseph Myers :
> On Wed, 27 Nov 2019, Maxim Kuvyrkov wrote:
>
> > IMO, we should aim to convert complete SVN history frozen at a specific
> > point. So that if we don't want to convert some of the branches or tags
> > to git, then we should delete them from SVN repository before
> > conversion
On Wed, 27 Nov 2019, Maxim Kuvyrkov wrote:
> IMO, we should aim to convert complete SVN history frozen at a specific
> point. So that if we don't want to convert some of the branches or tags
> to git, then we should delete them from SVN repository before
> conversion.
Sure, we could do that.
> On Nov 25, 2019, at 7:07 PM, Joseph Myers wrote:
>
> I'm looking at the sets of branches and tags resulting from a GCC
> repository conversion with reposurgeon.
>
> 1. I see 227 branches (and one tag) with names like
> cxx0x-concepts-branch-deleted-r131428-1 (this is out of 780 branches in
On Tue, 26 Nov 2019, Eric S. Raymond wrote:
> Joseph Myers :
> > Thanks. We've accumulated a lot of merge requests on the gcc-conversion
> > repository, once those are merged I'll test a further change to remove
> > those tags.
>
> I just checked; a rebase button appeared on your MRs and I mer
Joseph Myers :
> Thanks. We've accumulated a lot of merge requests on the gcc-conversion
> repository, once those are merged I'll test a further change to remove
> those tags.
I just checked; a rebase button appeared on your MRs and I merged all
three, but no rebase option occurs on Richard Ear
On Tue, 26 Nov 2019, Eric S. Raymond wrote:
> Joseph Myers :
> > A further note: in a previous run of the conversion I didn't see any
> > emptycommit-* tags. In my most recent conversion run, I see 4070 such
> > tags. How do I tell reposurgeon never to create such tags? Or should I
> > add a
Joseph Myers :
> A further note: in a previous run of the conversion I didn't see any
> emptycommit-* tags. In my most recent conversion run, I see 4070 such
> tags. How do I tell reposurgeon never to create such tags? Or should I
> add a tag deletion command for them in gcc.lift, once tag de
On Mon, 25 Nov 2019, Eric S. Raymond wrote:
> I knew there was a problem with those, but I have not diagnosed it
> yet. I know generally where it has to be and think it will be
> relatively easy to clean up once I've dealt with the more pressing
> issues.
>
> Please file issues about these bugs
Joseph Myers :
> I'm looking at the sets of branches and tags resulting from a GCC
> repository conversion with reposurgeon.
>
> 1. I see 227 branches (and one tag) with names like
> cxx0x-concepts-branch-deleted-r131428-1 (this is out of 780 branches in
> total in a conversion of GCC history a
I'm looking at the sets of branches and tags resulting from a GCC
repository conversion with reposurgeon.
1. I see 227 branches (and one tag) with names like
cxx0x-concepts-branch-deleted-r131428-1 (this is out of 780 branches in
total in a conversion of GCC history as of a few days ago). Can
51 matches
Mail list logo
