config.guess => i686-pc-cygwin
$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /cygdrive/e/gcc-4.0.2/configure
Thread model: single
gcc version 4.0.2
I didn't take any special action regarding "Whether you enabled all
languages or a subset of them." (accepted defaults)
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
On 2005-10-20 14:46:36 +0200, Paolo Bonzini wrote:
> I agree. For example, Fink on the Mac only has svn 1.1 (not that this
> is a showstopper IMHO),
FYI, DarwinPorts currently has svn 1.2.3, which can be installed
very easily.
> and Debian testing is "stuck" with the latest 3.8 openssh.
Why no
On 2005-10-19 17:12:32 +0200, Arnaud Charlet wrote:
> > The ssh multiplexing stuff just written up on the wiki should help.
>
> Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
> so I cannot test that right now.
For those without OpenSSH >= 4.0, can't fsh be a solution?
(AFA
There have been no answers on the following point...
On 2005-10-19 16:44:59 +0200, Arnaud Charlet wrote:
> $ svn log Makefile.in | more
>
> figure out that the last two revs are 105364 and 103893 (and now I
> guess I understand svn status --verbose output).
These are the last two revs *up to* yo
Richard Henderson <[EMAIL PROTECTED]> wrote:
> Yes. We check peep2_current_count to validate this.
I'd like to take a look at why peep2_current_count doesn't work
as expected for the problematic case. Thanks for the suggestion.
Regards,
kaz
On Fri, 2005-10-21 at 02:19 +0200, Lars Gullik Bjønnes wrote:
> Bernd Schmidt <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> | > It seems that svn is unable to send all its requests to the svn
> | > repo over one ssh connection. In one test I just did I had to enter
> | > the ssh p
On Thursday 20 October 2005 19:12, Jim Wilson wrote:
> See http://gcc.gnu.org/projects/gomp/
>
> This is still in early stages of implementation. Don't expect anything
> to work yet.
>
Indeed.
The implementation is at a stage where the C front end can be tested with
benchmarks (openmpbench_C an
> > 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
Lars Gullik Bj=F8nnes wrote:
> It seems that svn is unable to send all its requests to the svn
> repo over one ssh connection. In one test I just did I had to enter
> the ssh password five times.
man ssh-agent
You're missing the point: he's making an efficiency argument. Name
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
>
Bernd Schmidt <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > It seems that svn is unable to send all its requests to the svn
| > repo over one ssh connection. In one test I just did I had to enter
| > the ssh password five times.
|
| man ssh-agent
The connection is still set up fiv
Lars Gullik Bjønnes wrote:
It seems that svn is unable to send all its requests to the svn
repo over one ssh connection. In one test I just did I had to enter
the ssh password five times.
man ssh-agent
Bernd
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Oct 20, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote:
>
>> I'm very concerned that we're greating increasing the barrier to entry for
>> work on GCC. cvs is very intuitive and simple to use.
>
> The same can be said of svn, so it's not like a gre
Alexandre Oliva <[EMAIL PROTECTED]> writes:
| On Oct 20, 2005, Daniel Berlin <[EMAIL PROTECTED]> wrote:
|
| > svn diff -r1:r2 is only slow in the very small diff case, where ssh
| > handshake time dominates the amount of data to be transferred.
|
| And then, cvs diff -r1 -r2 also requires a ssh
On Thu, Oct 20, 2005 at 06:15:38PM -0400, Richard Kenner wrote:
> There already IS real documentation, and it's very good.
>
> http://svnbook.red-bean.com/
>
> Actually, I just went to that site and the latest printable (i.e., PDF)
> version I can find there is for version 1.1. Is that
Daniel Berlin <[EMAIL PROTECTED]> writes:
| > I'd also remember that this issue (diff of a single file across SSH being
| > slower) can be fixed by either an OpenSSH upgrade (which should be flawless
| > in many cases), or a svn:// readonly access (which I still have to
| > understand if it can be
Piotr Wyderski wrote:
Why isn't c destroyed at the very end? Is it a bug or a correct behaviour?
It is a bug. Where the bug lies depends on lots of info you left out,
such as the gcc version, the binutils version, and the target. See
http://gcc.gnu.org/bugs.html
for info on how to submi
x z wrote:
Is gcc optimized for thread level parallelism, in view of the recent
development of SMT and multicore architectures?
No, but we are working on OpenMP support, which is somewhat related.
This isn't automatic parallelization; it requires programmer
instrumentation via pragmas. This
Snapshot gcc-4.0-20051020 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051020/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20051020
You'll
There already IS real documentation, and it's very good.
http://svnbook.red-bean.com/
Actually, I just went to that site and the latest printable (i.e., PDF)
version I can find there is for version 1.1. Is that going to be good enough?
Kevin Handy <[EMAIL PROTECTED]> writes:
> Would it be possible to write a cvs read-only interface to the
> svn database? i.e. replace the cvs server with a svn-cvs emulation
> layer.
In principle, sure, why not? The CVS client server protocol is well
documented.
In practice sounds like quite a
I have been using the gcc 3.4.4 GNAT compiler to compile an existing Ada
program on an HP-UX 11 system.
We have noticed that generated images of floating-point numbers often
appear with the least-significant digit incremented by 1. Since the
application is used in a calibration laboratory, this
On Oct 20, 2005, at 2:45 AM, Arnaud Charlet wrote:
Note that I found it a real pain to have to install so much
dependency package
on my linux system, so I suspect building the whole dependency
packages under
non linux systems might be slghtly of a pain.
I'm on darwin, grabbed tarball, built
Ian Lance Taylor wrote:
Richard Guenther <[EMAIL PROTECTED]> writes:
If it is at all possible we should probably try to keep read-only CVS working
(and up-to-date) for HEAD and release-branches. This will allow occasional
contributors and technically-less-provided people to continue workin
Ian Lance Taylor wrote:
Uros Bizjak <[EMAIL PROTECTED]> writes:
There is no post-reload cse_condition_code_reg () pass, so perhaps we
have to add one. A cse_condition_code_reg () walks all instructions by
itself, so I'm not sure if some existing post-reload CSE pass could be
enhanced.
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Oct 20, 2005 at 03:12:30PM +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | I have absolutely no reason to expect the feedback process to change if
| > | we waited. I have absolutely no reason to
Daniel Berlin wrote:
On Thu, 2005-10-20 at 11:06 -0700, David Daney wrote:
I just did an unapproved commit to the svn repository (r105372) on the
theory that it is still a test repository.
This is permitted isn't it?
Sure.
One thing that happened is that all the bugzilla bugs th
On Mon, Oct 17, 2005 at 10:56:01AM -0700, Jim Wilson wrote:
>Peter Barada wrote:
>>Does the uberbaum tree exist on savanna, or is it only on
>>sources.redhat.com? If so, what is the procedure for accessing it?
>
>I would not recommend use of uberbaum. There are some old-time
>ex-Cygnus hackers t
On Oct 20, 2005, at 10:45 AM, Daniel Berlin wrote:
For the curious, my goal for 1.4 is to have it under 500 meg in
size, if
at all possible.
svn edit (hard link, then have edit break the link), and making use
of union filesystems might be two easy things to do that can reclaim
lots of spa
On Thu, 2005-10-20 at 11:06 -0700, David Daney wrote:
> I just did an unapproved commit to the svn repository (r105372) on the
> theory that it is still a test repository.
>
> This is permitted isn't it?
Sure.
>
> One thing that happened is that all the bugzilla bugs that were
> referenced go
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.
I just did an unapproved commit to the svn repository (r105372) on the
theory that it is still a test repository.
This is permitted isn't it?
One thing that happened is that all the bugzilla bugs that were
referenced got updated as well. But this is in the live bugzilla.
Did I do something
There already IS real documentation, and it's very good.
http://svnbook.red-bean.com/
The online help provided by "svn help" is also very good as a quick
reference.
No, I don't mean documentation of svn (I assumed it had a manual ...),
I mean a replacement for the information
On Thursday 20 October 2005 18:34, Richard Kenner wrote:
> Ideally, once this discussion is over, some kind subversion expert
> will update the wiki to contain the answers to the questions raised on this
> thread.
>
> Ideally once this discussion is over, the information will be in real
> docu
Joe Buck wrote:
> Another possibility is to increase the frequency of snapshots after
> the switch to subversion. They will have a lower cost, since it will
> no longer be necessary to lock the database for an hour to attach the
> snapshot tag. Or maybe no tag is necessary at all for snapshots,
So, after staring at the working copy to look at ways to reduce size, it
turns out i foo-barred the conversion command line slightly in my last
conversion, and it's setting the eol-style property on every single file
(it ignored my misspelled option :P).
I've done this conversion about 80 billion
Make that *more* efficiently. AFAIK svn is much more efficient than
cvs by default in all cases, except for disk space use.
Arno's numbers seem to disagree with you there.
Ideally, once this discussion is over, some kind subversion expert will
update the wiki to contain the answers to the questions raised on this
thread.
Ideally once this discussion is over, the information will be in real
documentation, not just the wiki ...
> What I keep seeing are increasingly complex solutions in order to keep
> efficiency the same as it is now.
Ah, come on. That just takes some getting used to.
In *some* cases, indeed I'm seeing "do it this way instead of that way" where
the suggested way isn't more complicated,
On Thu, Oct 20, 2005 at 07:46:52AM -0700, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
> > I don't think keeping the CVS repository up to date after the move to
> > subversion is worthwhile
>
> I agree.
>
> I think that keeping CVS up-to-date is not a good use of resources; when
> we switch,
On Thu, Oct 20, 2005 at 03:12:30PM +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I have absolutely no reason to expect the feedback process to change if
> | we waited. I have absolutely no reason to believe this won't happen
> | again when svn 1.4 com
On Thu, 2005-10-20 at 10:04 -0700, Joe Buck wrote:
> Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> > > I'm looking forward to solutions that lower the entry barrier,
> > > specifically with repect too OpenSSH, diff and svk.
>
> I think we should try to optimize the read-only access case, since la
On Thu, Oct 20, 2005 at 08:42:25AM -0400, Daniel Berlin wrote:
> So far, the feedback process has looked like:
>
> 1. I've given people months to consider the change, it's not until the
> last few days that anybody who seems to complain even bothers to try it.
It always works that way. The probl
On Thu, Oct 20, 2005 at 11:55:30PM +0900, Kaz Kojima wrote:
> Is it assumed that peep2_next_insn never return PEEP2_EOB in change_state?
Yes. We check peep2_current_count to validate this.
> If so, what target bug is most likely?
Dunno. This peep2_current_count is a relatively recent change.
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> > I'm looking forward to solutions that lower the entry barrier,
> > specifically with repect too OpenSSH, diff and svk.
On Thu, Oct 20, 2005 at 11:51:28AM +0200, Giovanni Bajo wrote:
> I'm going to write something in the wiki about svk. There's much
On Oct 20, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote:
> I'm very concerned that we're greating increasing the barrier to entry for
> work on GCC. cvs is very intuitive and simple to use.
The same can be said of svn, so it's not like a great barrier increase.
> I'm not seeing the same thing
On Thu, Oct 20, 2005 at 12:20:17PM -0400, Daniel Berlin wrote:
> On Thu, 2005-10-20 at 09:39 -0500, Bobby McN wrote:
> > Daniel Berlin wrote:
> >
> > >
> > Daniel, I don't have an account with the repository.
> > How would I set my computer up to get the gcc code anonymously?
> > All i do is compi
Uros Bizjak <[EMAIL PROTECTED]> writes:
> There is no post-reload cse_condition_code_reg () pass, so perhaps we
> have to add one. A cse_condition_code_reg () walks all instructions by
> itself, so I'm not sure if some existing post-reload CSE pass could be
> enhanced.
The cse_condition_code_reg
Frédéric PRACA wrote:
Hello,
I'm trying to build a cross-compiler for RTEMS. Building C or C++ cross-compiler
is not a problem but building the Ada compiler does'nt work. In fact, even
building a normal compiler does'nt work at all. The main reason I found is that
the gcc driver of FreeBSD doesn'
Frédéric PRACA wrote:
Hello,
I'm trying to build a cross-compiler for RTEMS. Building C or C++ cross-compiler
is not a problem but building the Ada compiler does'nt work. In fact, even
building a normal compiler does'nt work at all. The main reason I found is that
the gcc driver of FreeBSD doesn'
On 2005-10-20, at 16:57, Richard Kenner wrote:
Sorry about that, but let's not remember of the other dozens which
works on branches and can do a merge in seconds instead of
literally
*hours*, and so on.
Yes, but how often do even those who work on branches a lot do merges?
If no
On Thursday 20 October 2005 16:57, Richard Kenner wrote:
> Sorry about that, but let's not remember of the other dozens which
> works on branches and can do a merge in seconds instead of literally
> *hours*, and so on.
>
> Yes, but how often do even those who work on branches a lot do m
On Oct 20, 2005, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> svn diff -r1:r2 is only slow in the very small diff case, where ssh
> handshake time dominates the amount of data to be transferred.
And then, cvs diff -r1 -r2 also requires a ssh handshake, so I don't
get what it is that people have bee
On Thursday 20 October 2005 15:33, Daniel Jacobowitz wrote:
> I eagerly look forward to svn.
Yay. Agreed.
Gr.
Steven
On Thu, 2005-10-20 at 08:52 -0700, Ian Lance Taylor wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
>
> > If it is at all possible we should probably try to keep read-only CVS
> > working
> > (and up-to-date) for HEAD and release-branches. This will allow occasional
> > contributors and te
On Thu, 2005-10-20 at 09:39 -0500, Bobby McN wrote:
> Daniel Berlin wrote:
>
> >
> Daniel, I don't have an account with the repository.
> How would I set my computer up to get the gcc code anonymously?
> All i do is compile the code to make sure it will work with i686-pc-cygwin.
> Bobby
>
You ca
Richard Guenther <[EMAIL PROTECTED]> writes:
> If it is at all possible we should probably try to keep read-only CVS working
> (and up-to-date) for HEAD and release-branches. This will allow occasional
> contributors and technically-less-provided people to continue working in
> submit-patch mode
Mike Stump wrote:
> On Oct 19, 2005, at 2:56 AM, François-Xavier Coudert wrote:
>
>> Or am I the only person to find that disk is expensive (or working
>> on his own hardware, maybe)?
>
>
> A checkout costs US$0.50. This is around 2.6x more expensive than a
> cvs checkout. Check around locally
Hello,
I'm trying to build a cross-compiler for RTEMS. Building C or C++ cross-compiler
is not a problem but building the Ada compiler does'nt work. In fact, even
building a normal compiler does'nt work at all. The main reason I found is that
the gcc driver of FreeBSD doesn't support ada and it see
Less often than needed or wanted, because it takes way too much time
to do one, instead of few seconds as it should. One may want to merge
a development branch every day or so, but it can't be done right now
because the overhead of the operation is too high. This causes people
t
(I'm sorry that I'm breaking threading, but I don't feel to bad about this given
whom I'm replying to, it's not like I'm cutting a huge thread in two)
Richard Kenner wrote:
> I must say that I find the amount of "fiddling" and special options or
> configurations needed here very disturbing. Peop
Hello Steven!
> And FWIW, it is IMHO bad practice in general to just add new passes,
> instead of investigating why existing passes don't do the job and how
> they can be enhanced to do the job better.
There is no post-reload cse_condition_code_reg () pass, so perhaps we
have to add one. A cse_co
Richard Kenner writes:
> What I keep seeing are increasingly complex solutions in order to
> keep efficiency the same as it is now. This is a very large
> distributed cost, which can't be ignored.
No, but neither should the cost be puffed up, as it is being at the
moment. SSH connection cach
Richard Kenner <[EMAIL PROTECTED]> wrote:
> Sorry about that, but let's not remember of the other dozens which
> works on branches and can do a merge in seconds instead of literally
> *hours*, and so on.
>
> Yes, but how often do even those who work on branches a lot do merges?
Less
Hi,
I've got an ICE during glibc build with the current mainline on
sh4-unknown-linux-gnu:
../sysdeps/ieee754/flt-32/k_rem_pio2f.c: In function '__kernel_rem_pio2f':
../sysdeps/ieee754/flt-32/k_rem_pio2f.c:213: internal compiler error:
Segmentation fault
It doesn't fail with 20051003 compiler.
Sorry about that, but let's not remember of the other dozens which
works on branches and can do a merge in seconds instead of literally
*hours*, and so on.
Yes, but how often do even those who work on branches a lot do merges?
If not very often, why not just start it up, background it,
I'm going to write something in the wiki about svk. There's much FUD
spreading in this thread. DanJ put up a wiki page on the OpenSSH
configuration (which really could be found with 3 minutes of googling,
which is shorter than writing a mail asking information about it [not
spe
Joseph S. Myers wrote:
> I don't think keeping the CVS repository up to date after the move to
> subversion is worthwhile
I agree.
I think that keeping CVS up-to-date is not a good use of resources; when
we switch, we switch. If for some reason we have to switch back, we
switch back. Let's no
Daniel Berlin wrote:
I'd also remember that this issue (diff of a single file across SSH being
slower) can be fixed by either an OpenSSH upgrade (which should be flawless
in many cases), or a svn:// readonly access (which I still have to
understand if it can be done),
svn:// readonly acc
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 Jacobowitz <[EMAIL PROTECTED]> writes:
[...]
| I think that
| was a good choice; I'm sorry that people are crawling out from
| every which way now to object to the entire idea.
I haven't seen people object to the idea of moving away
Daniel Berlin <[EMAIL PROTECTED]> writes:
| > | the problem is probably going to be fixed by SVN 1.4 and
| > | the new svn+ssl:// protocol. Meanwhile, unlucky people will have to live
with a
| > | slower "svn diff -rR1 -rR2" remote operation. Sorry about that, but let's
not
| > | remember of the
> I'd also remember that this issue (diff of a single file across SSH being
> slower) can be fixed by either an OpenSSH upgrade (which should be flawless
> in many cases), or a svn:// readonly access (which I still have to
> understand if it can be done),
svn:// readonly access is up and running
On Thu, 2005-10-20 at 14:09 +0200, Gabriel Dos Reis wrote:
> "Giovanni Bajo" <[EMAIL PROTECTED]> writes:
>
>
> [...]
>
> | Even if we assume that it's impossible to upgrade OpenSSH on a given
> platform
> | for some weird reason,
>
> I appreciate your effort in this, but I strongly suggest tha
On Thu, Oct 20, 2005 at 12:11:20PM +0200, Arnaud Charlet wrote:
> > DanJ put up a wiki page on the OpenSSH configuration (which really could be
> > found with 3 minutes of googling, which is shorter than writing a mail
> > asking
> > information about it [not speaking of you, gaby]).
>
> Well, wi
* 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?
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
[...]
| In other words, what I see mostly in this thread is that people are worried
| because of what we usually call "micro-benchmarks" (e.g. "raw cvs diff time
| for a single time across two revisions"),
People have been asked to voice their concerns
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| I have absolutely no reason to expect the feedback process to change if
| we waited. I have absolutely no reason to believe this won't happen
| again when svn 1.4 comes out.
So why are people asked to voice their opinions if there is so much
dis
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>> Even if we assume that it's impossible to upgrade OpenSSH on a given
>> platform for some weird reason,
>
> I appreciate your effort in this, but I strongly suggest that you
> refrain from calling reasons why people can't install the latest
> versions
| Even if we assume that it's impossible to upgrade OpenSSH on a given platform
| for some weird reason,
I appreciate your effort in this, but I strongly suggest that you
refrain from calling reasons why people can't install the latest
versions of supporting tools "weird".
I agree. For examp
On Thu, 2005-10-20 at 12:11 +0200, Arnaud Charlet wrote:
> Same for saying "this will be improved in the next version of svn".
> It is assuming that upgrading versions of svn clients for people is a no
> cost operation, which is again not the case in practice.
>
> And maybe if svn 1.4 will improv
On Thu, 2005-10-20 at 11:51 +0200, Giovanni Bajo wrote:
> Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>
> > I'm looking forward to solutions that lower the entry barrier,
> > specifically with repect too OpenSSH, diff and svk.
>
>
> I'm going to write something in the wiki about svk. There's muc
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
[...]
| Even if we assume that it's impossible to upgrade OpenSSH on a given platform
| for some weird reason,
I appreciate your effort in this, but I strongly suggest that you
refrain from calling reasons why people can't install the latest
versions
On 10/20/05, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> Since there is a big brainstorming, I will sum up my opinion here (and
> then stop spending time on this issue). From the discussion, it looks
> like the switch seems the most important constraint imposed by the switch
> is about har
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Giovanni Bajo wrote:
[...]
>>- time to do an update on mainline/branch
>
>
> When updating, cvs/svn first try to find out what needs to be updated (in
> rough
> terms) and then start downloading the updates. The latter part (download) is
> obviously
Since there is a big brainstorming, I will sum up my opinion here (and
then stop spending time on this issue). From the discussion, it looks
like the switch seems the most important constraint imposed by the switch
is about hardware/software requirements, and I do strongly second this
point.
For e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arnaud Charlet wrote:
>
> In your world, everyone has an up-to-date version of every tool,
> and have e.g. the latest OpenSSH and subversion clients installed
> on his machine. In mine, this is clearly far from being the case:
> no svn installed, and
On Oct 20, 2005 12:11 PM, Arnaud Charlet <[EMAIL PROTECTED]> wrote:
> And maybe if svn 1.4 will improve such important improvements, it
> would
> be a good idea to wait till svn 1.4 is outt so that people do not have
> to
> upgrade multiple times to get "the expected" behavior.
By then, I'm sure,
On 2005-10-20, at 11:45, Arnaud Charlet wrote:
Note that I found it a real pain to have to install so much
dependency package
on my linux system, so I suspect building the whole dependency
packages under
non linux systems might be slghtly of a pain.
This is not the case. This is only due t
On 10/20/05, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Eric Botcazou <[EMAIL PROTECTED]> wrote:
>
> > I've never created/managed branches or tagged anything in the GCC
> > tree. The important things to me are:
> >
> > - time to do a complete check-out on mainline/branch
>
> Check-out is 30% slowe
On Thu, Oct 20, 2005 at 09:17:02AM +0200, Volker Reichelt wrote:
> I just wanted to know what's the state of the gomp branch w.r.t
> bug reports. Does it make sense to already send bug reports to
> you or even add them to bugzilla?
I think so. We are getting near the point where we're looking
for
> DanJ put up a wiki page on the OpenSSH configuration (which really could be
> found with 3 minutes of googling, which is shorter than writing a mail asking
> information about it [not speaking of you, gaby]).
Well, with all your respect, you seem to be living in a different world than
mine.
In
Arnaud Charlet <[EMAIL PROTECTED]> wrote:
>>> - portability of svn to non-Linux systems
>>
>> This has been answered already. It should not be an issue.
>
> Note that I found it a real pain to have to install so much
> dependency package on my linux system, so I suspect building the
> whole depend
Giovanni Bajo writes:
> Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>
> > I'm looking forward to solutions that lower the entry barrier,
> > specifically with repect too OpenSSH, diff and svk.
>
>
> I'm going to write something in the wiki about svk. There's much FUD
> spreading
> in t
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> I'm looking forward to solutions that lower the entry barrier,
> specifically with repect too OpenSSH, diff and svk.
I'm going to write something in the wiki about svk. There's much FUD spreading
in this thread.
DanJ put up a wiki page on the OpenSSH
A few comments, since your message makes it sound like everything is
better, which is not true in reality.
> > - time to do a diff on mainline/branch
>
> "svn diff" is a disconnected operation, requires no server access, so it takes
> milliseconds. "cvs diff" is dominated by network connection, s
Eric Botcazou <[EMAIL PROTECTED]> wrote:
> I've never created/managed branches or tagged anything in the GCC
> tree. The important things to me are:
>
> - time to do a complete check-out on mainline/branch
Check-out is 30% slower because of the time needed to write the duplicate local
copy. On t
On 10/20/05, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Oct 2005, Richard Guenther wrote:
>
> > If it is at all possible we should probably try to keep read-only CVS
> > working
> > (and up-to-date) for HEAD and release-branches. This will allow occasional
> > contributors and techni
On Oct 20, 2005 11:01 AM, Eric Botcazou <[EMAIL PROTECTED]>
wrote:
> - portability of svn to non-Linux systems
http://subversion.tigris.org/faq.html#portability
Gr.
Steven
1 - 100 of 113 matches
Mail list logo
