Daniel Berlin <[EMAIL PROTECTED]> writes:
> Karl, Ben, have you ever seen a lengthy discussion indicating that
> compressed and no-text base working copies are unlikely to happen?
I once expressed the sentiment that compressed text bases were not as
desirable as simply optional text bases, and sai
So, collecting together the response to last night's mail:
Status of PR 19292 metabug:-
5900 The penultimate entry says -
I would like to propose that this bug be closed. This is about as
good as it
gets. We should set up some automatic regression testing on LAPACK
from hence
forth.
Let
--- Paul Thomas <[EMAIL PROTECTED]> wrote:
> Thomas,
>
> >Currently, gfortran is in a half-usable state. It is not yet
> >ready as a replacement for g77 (see PR 19292) and there are quite
> >a lot of things it gets wrong with Fortran 95.
> >
> I think that this is way too strong. Of the outst
The following 2 bugs have patches submitted:
On Oct 21, 2005, at 5:06 PM, Paul Thomas wrote:
19425 Duplicate SAVE attribute problem - illegal f95 and questionable
f77
22282 loc intrinsic and %loc construction is not implemented in
gfortran - do-able but not a disaster.
-- Pinski
Thomas,
Currently, gfortran is in a half-usable state. It is not yet
ready as a replacement for g77 (see PR 19292) and there are quite
a lot of things it gets wrong with Fortran 95.
I think that this is way too strong. Of the outstanding PR19292 "bugs":
5900 The penultimate entry says -
I
On 10/19/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> Karl, Ben, have you ever seen a lengthy discussion indicating that
> compressed and no-text base working copies are unlikely to happen?
Au contraire, the feature has been in our to-do list (issue tracker)
for years. We even accepted a Summe
On Fri, 2005-10-21 at 06:56 +0200, Paul Thomas wrote:
> Dear All,
>
> >>I spent nearly 5 hours yesterday reading the svn FAQ, mailing list
> >>archives, and the docs. I never came across this solution.
> >>
> >>
> Could somebody please distill the wisdom from this thread onto the
> Wiki? I
Paul Thomas wrote:
>>>I spent nearly 5 hours yesterday reading the svn FAQ, mailing list
>>>archives, and the docs. I never came across this solution.
>>>
>>>
>
> Could somebody please distill the wisdom from this thread onto the
> Wiki? I can understand why Steve might send 5 hours on it.
Dear All,
I spent nearly 5 hours yesterday reading the svn FAQ, mailing list
archives, and the docs. I never came across this solution.
Could somebody please distill the wisdom from this thread onto the
Wiki? I can understand why Steve might send 5 hours on it. It's bad
that one person
> > I actually forgot the dumbest and easiest solution, that works fine,
> > that is, to use svn switch.
> >
> > checkout a gcc copy.
> >
> > go to the gcc subdir
> >
> > svn switch svn+ssh://[EMAIL PROTECTED]/svn/gcc/emptydir ada
> >
> > repeat for each dir you don't want.
> >
> > This allow
On Thu, Oct 20, 2005 at 02:10:36PM -0400, Daniel Berlin wrote:
> On Thu, 2005-10-20 at 07:25 -0700, Steve Kargl wrote:
> > On Thu, Oct 20, 2005 at 02:47:19PM +0200, Florian Weimer wrote:
> > > * Daniel Berlin:
> > >
> > > > You could simply do non-recursive checkouts (svn co -N) of the dirs you
>
On Thu, 2005-10-20 at 07:25 -0700, Steve Kargl wrote:
> On Thu, Oct 20, 2005 at 02:47:19PM +0200, Florian Weimer wrote:
> > * Daniel Berlin:
> >
> > > You could simply do non-recursive checkouts (svn co -N) of the dirs you
> > > want.
> > > SVN doesn't care how you piece together the working copy.
On Thu, Oct 20, 2005 at 02:47:19PM +0200, Florian Weimer wrote:
> * Daniel Berlin:
>
> > You could simply do non-recursive checkouts (svn co -N) of the dirs you
> > want.
> > SVN doesn't care how you piece together the working copy.
>
> Doesn't "commit -N" cause the working copy to become fragmen
* Daniel Berlin:
> You could simply do non-recursive checkouts (svn co -N) of the dirs you
> want.
> SVN doesn't care how you piece together the working copy.
Doesn't "commit -N" cause the working copy to become fragmented, so
that you cannot issue a working-copy-wide commit or diff anymore?
On Wed, 2005-10-19 at 19:43 -0700, Kean Johnston wrote:
> > I saw no postings that contained anything like a design for doing this,
> > etc, to the dev list from you.
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=106243
>
Oh that one, i'm sorry, i confused your thread with anothe
I saw no postings that contained anything like a design for doing this,
etc, to the dev list from you.
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=106243
Of course, you seem represent this thread you started as having actually
involved any subversion developers, which it didn't
On Wed, 2005-10-19 at 16:55 -0700, Kean Johnston wrote:
> >>I fear the impending switch to subversion will have a negative impact on
> >>the future development of gfortran due the rather limited number of people
> >>who actually supply patches and the sudden increase in hardware
> >>requirements.
I fear the impending switch to subversion will have a negative impact on
the future development of gfortran due the rather limited number of people
who actually supply patches and the sudden increase in hardware
requirements. For example, I find
troutmask:sgk[204] du -sh gcc40 gcc41 trunk 241
On Wed, Oct 19, 2005 at 05:06:40PM -0400, Andrew Pinski wrote:
> GCC and gfortran (and gcj) should all play by the normal rules that we
> made to GCC so that we don't spend too much time backporting (and
> looking backwards) instead of fixing bugs.
gfortran is the replacement for g77, and it still
On Wed, Oct 19, 2005 at 03:36:08PM -0400, Daniel Berlin wrote:
> On Wed, 2005-10-19 at 12:16 -0700, Steve Kargl wrote:
> > On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:
>
> > OK, I'll go read about svk. I scanned the svn docs for an
> > --exclude-dir= option or .svnrc file wher
On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote:
> Dude, I hope fortran will, after branching of 4.1, follow the usual rules
> of regression fixes only.
Currently, gfortran is in a half-usable state. It is not yet
ready as a replacement for g77 (see PR 19292) and there are quite
On Oct 19, 2005, at 4:36 PM, FX Coudert wrote:
A regression is a bug that was not in release N - M and was discovered
in release N. You are then free to fix N - M + 1 to N. Like you have
a testcase that crashes gfortran on 4.1.0, but did not on 4.0.2.
But then, you'll explain people that th
FX,
The fortran patches are always fortran-contained, and I think if the
community thinks it worth to have a different development model (until
some point in the future, defined in advance) why shouldn't it be so?
This might well be the value of keeping the binaries going. From what I
can
A regression is a bug that was not in release N - M and was discovered
in release N. You are then free to fix N - M + 1 to N. Like you have
a testcase that crashes gfortran on 4.1.0, but did not on 4.0.2.
But then, you'll explain people that they won't have a decent fortran
compiler in distro
On 10/19/05, Steve Kargl <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote:
> > On 10/19/05, Tobias Schl?ter <[EMAIL PROTECTED]> wrote:
> > > Steve Kargl wrote:
> > > > Now, to my proposal for future gfortran development post 4.1 branching.
> > > > When (
On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote:
> On 10/19/05, Tobias Schl?ter <[EMAIL PROTECTED]> wrote:
> > Steve Kargl wrote:
> > > Now, to my proposal for future gfortran development post 4.1 branching.
> > > When (if) svn becomes the source code revision tool, I propose that
On 10/19/05, Tobias Schlüter <[EMAIL PROTECTED]> wrote:
>
> [ I've added gcc@ to the CC list and reproduced the message in full, FX
> already got the "buy a bigger harddisk" answer there, I think it makes sense
> to show that other people care about this, too ]
>
> Steve Kargl wrote:
> > Now, to my
On Wed, 2005-10-19 at 12:16 -0700, Steve Kargl wrote:
> On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:
> OK, I'll go read about svk. I scanned the svn docs for an
> --exclude-dir= option or .svnrc file where excluding directories
> could be done. So far, I've come up empty. I
Steve Kargl wrote:
> On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:
>
>>>694Msvn40 <-- svn 4.0 branch 694Msvn41 <-- svn 4.1 branch 694M
>>>trunk <-- svn mainline
>>>
>>>Now add one or two additional svn directories for large change sets and
>>>this becomes intolerab
On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:
> >
> > 694Msvn40 <-- svn 4.0 branch 694Msvn41 <-- svn 4.1 branch 694M
> > trunk <-- svn mainline
> >
> > Now add one or two additional svn directories for large change sets and
> > this becomes intolerable. (Before a
[ I've added gcc@ to the CC list and reproduced the message in full, FX
already got the "buy a bigger harddisk" answer there, I think it makes sense
to show that other people care about this, too ]
Steve Kargl wrote:
> I fear the impending switch to subversion will have a negative impact on
> the
31 matches
Mail list logo
