Joseph Myers :
> On Mon, 9 Jul 2018, Alexandre Oliva wrote:
>
> > On Jul 9, 2018, Jeff Law wrote:
> >
> > > On 07/09/2018 01:57 PM, Eric S. Raymond wrote:
> > >> Jeff Law :
> > >>> I'm not aware of any such merges, but any that occurred most likely
> > >>> happened after mid-April when the trun
Joseph Myers :
> On Mon, 9 Jul 2018, Eric S. Raymond wrote:
>
> > Richard Biener :
> > > 12 hours from remote I guess? The subversion repository is available
> > > through rsync so you can create a local mirror to work from (we've been
> > > doing that at suse for years)
> >
> > I'm saying I s
On Tue, 10 Jul 2018, Jonathan Wakely wrote:
> > Large-scale, I'm afraid. The context diff is about a GLOC.
>
> I don't see how that's possible. Most of those files are tiny, or
> change very rarely, so I don't see how that large a diff can happen.
Concretely, the *complete GCC source tree* (tru
On Mon, 9 Jul 2018, Alexandre Oliva wrote:
> On Jul 9, 2018, Jeff Law wrote:
>
> > On 07/09/2018 01:57 PM, Eric S. Raymond wrote:
> >> Jeff Law :
> >>> I'm not aware of any such merges, but any that occurred most likely
> >>> happened after mid-April when the trunk was re-opened for development
On Mon, 9 Jul 2018, Eric S. Raymond wrote:
> Richard Biener :
> > 12 hours from remote I guess? The subversion repository is available
> > through rsync so you can create a local mirror to work from (we've been
> > doing that at suse for years)
>
> I'm saying I see rsync plus local checkout ta
"Eric S. Raymond" writes:
> I'm saying I see rsync plus local checkout take 10-12 hours.
The rsync is a one-off cost. Once you have the repository locally you
can checkout any individual revision much more quickly. I have a local
copy of the gcc repository and a checkout of gcc trunk from loca
Jonathan Wakely :
> On Tue, 10 Jul 2018 at 09:19, Jonathan Wakely wrote:
> >
> > On Mon, 9 Jul 2018 at 21:00, Eric S. Raymond wrote:
> > >
> > > Bernd Schmidt :
> > > > On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> > > > > Last time I did a comparison between SVN head and the git conversion
>
On Tue, 10 Jul 2018 at 09:19, Jonathan Wakely wrote:
>
> On Mon, 9 Jul 2018 at 21:00, Eric S. Raymond wrote:
> >
> > Bernd Schmidt :
> > > On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> > > > Last time I did a comparison between SVN head and the git conversion
> > > > tip they matched exactly.
On Mon, 9 Jul 2018 at 21:00, Eric S. Raymond wrote:
>
> Bernd Schmidt :
> > On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> > > Last time I did a comparison between SVN head and the git conversion
> > > tip they matched exactly. This time I have mismatches in the following
> > > files.
> >
> > S
On July 9, 2018 10:20:39 PM GMT+02:00, "Eric S. Raymond"
wrote:
>Richard Biener :
>> 12 hours from remote I guess? The subversion repository is available
>through rsync so you can create a local mirror to work from (we've been
>doing that at suse for years)
>
>I'm saying I see rsync plus local c
On Jul 9, 2018, Jeff Law wrote:
> On 07/09/2018 01:57 PM, Eric S. Raymond wrote:
>> Jeff Law :
>>> I'm not aware of any such merges, but any that occurred most likely
>>> happened after mid-April when the trunk was re-opened for development.
>> I'm pretty certain things were still good at r2560
Richard Biener :
> 12 hours from remote I guess? The subversion repository is available through
> rsync so you can create a local mirror to work from (we've been doing that at
> suse for years)
I'm saying I see rsync plus local checkout take 10-12 hours. I asked Jason
about this and his respon
Jeff Law :
> > I'm pretty certain things were still good at r256000. I've started that
> > check running. Not expecting results in less than twelve hours.
> r256000 would be roughly Christmas 2017. I'd be very surprised if any
> merges to the trunk happened between that point and early April.
On July 9, 2018 9:19:11 PM GMT+02:00, e...@thyrsus.com wrote:
>Last time I did a comparison between SVN head and the git conversion
>tip they matched exactly. This time I have mismatches in the following
>files.
>
>libtool.m4
>libvtv/ChangeLog
>libvtv/configure
>libvtv/testsuite/lib/libvtv.exp
>lt
On 07/09/2018 01:57 PM, Eric S. Raymond wrote:
> Jeff Law :
>>> There are brute-force ways to pin down such malformations, but none of
>>> them are practical at the huge scale of this repository. The main
>>> problem here wouldn't reposurgeon itself but the fact that Subversion
>>> checkouts on a
Bernd Schmidt :
> On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> > Last time I did a comparison between SVN head and the git conversion
> > tip they matched exactly. This time I have mismatches in the following
> > files.
>
> So what are the diffs? Are we talking about small differences (like o
Jeff Law :
> > There are brute-force ways to pin down such malformations, but none of
> > them are practical at the huge scale of this repository. The main
> > problem here wouldn't reposurgeon itself but the fact that Subversion
> > checkouts on a repo this large are very slow. I've seen a single
On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> Last time I did a comparison between SVN head and the git conversion
> tip they matched exactly. This time I have mismatches in the following
> files.
So what are the diffs? Are we talking about small differences (like one
change missing) or large-
On 07/09/2018 01:19 PM, Eric S. Raymond wrote:
> Last time I did a comparison between SVN head and the git conversion
> tip they matched exactly. This time I have mismatches in the following
> files.
>
> libtool.m4
> libvtv/ChangeLog
> libvtv/configure
> libvtv/testsuite/lib/libvtv.exp
> ltmain.s
19 matches
Mail list logo