Larry McVoy <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
>> > Err, "faster"? The following is the moral equiv of 4 kernel updates
>> > which had nothing to do using BitKeeper instead of CVS. The local copy
>> > was in San Francisco and the remote
Larry McVoy [EMAIL PROTECTED] wrote:
On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
Err, "faster"? The following is the moral equiv of 4 kernel updates
which had nothing to do using BitKeeper instead of CVS. The local copy
was in San Francisco and the remote copy is Cort's
On Thu, 14 Sep 2000, David A. Gatwood wrote:
> On Wed, 13 Sep 2000, mberglund wrote:
>
> > Because Linux already runs on a couple of platforms even NetBSD does not
> > run on,
>
> And vice-versa, last I checked. Let's be fair here. :-)
Indeed. Until Linux has support for the Sega Dreamcast
On Thu, 14 Sep 2000, David A. Gatwood wrote:
> On Wed, 13 Sep 2000, mberglund wrote:
>
> > Because Linux already runs on a couple of platforms even NetBSD does not
> > run on,
>
> And vice-versa, last I checked. Let's be fair here. :-)
>
>
> > PS: If FreeBSD DID run on PPC and S390 and
On Wed, 13 Sep 2000, mberglund wrote:
> Because Linux already runs on a couple of platforms even NetBSD does not
> run on,
And vice-versa, last I checked. Let's be fair here. :-)
> PS: If FreeBSD DID run on PPC and S390 and offer the company I work for
NetBSD runs on lots of PPC machines,
On Wed, 13 Sep 2000, mberglund wrote:
Because Linux already runs on a couple of platforms even NetBSD does not
run on,
And vice-versa, last I checked. Let's be fair here. :-)
PS: If FreeBSD DID run on PPC and S390 and offer the company I work for
NetBSD runs on lots of PPC machines,
On Thu, 14 Sep 2000, David A. Gatwood wrote:
On Wed, 13 Sep 2000, mberglund wrote:
Because Linux already runs on a couple of platforms even NetBSD does not
run on,
And vice-versa, last I checked. Let's be fair here. :-)
PS: If FreeBSD DID run on PPC and S390 and offer the
On Wed, 13 Sep 2000, Stephen Frazier wrote:
> Does *BSD run on S390?
Ummm, hello, NO they do not. This is at least PART of the point. I
believe now is my chance to get out my clue-by-four.
FreeBSD has a GREAT idea(and really NetBSD as well). We might want to
consider adopting that idea. In
On Tue, Sep 12, 2000 at 12:21:16AM +0200, Jamie Lokier wrote:
> > Other than the initial repository create (aka cvs checkout), BK
> > *never* moves an entire file across the wire. Never means never and
> > includes the process of deciding what to do. CVS moves whole files
> > just to discover
Does *BSD run on S390?
Stephen Frazier
Oklahoma Department of Corrections
-Original Message-
On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:
I just thought I would remind all the nay-sayers that the *BSD world has
been doing something along this line since at least 1990. While some of
On Tue, 12 Sep 2000, Ralf Baechle wrote:
> On Mon, Sep 11, 2000 at 02:39:42PM -0700, Larry McVoy wrote:
> > On the other hand, if you do a
> >
> > find . -type f | xargs touch
> > time cvs update .
> >
> > it will melt down your DSL line for what seems forever. I killed it after
> > 20
Jamie Lokier wrote:
> > @touch /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/arch.h
> > [...]
> .cvsignore
Oops, ignore me 'cos I obviously didn't read what I replied to.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Jamie Lokier writes:
> .cvsignore
Not so fast. Read your .hdepend file, notice which files that it's
touching, and then notice that those are real source files
(include/linux/*.h and include/asm/*.h).
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Ralf Baechle wrote:
> >From some random Linux source tree's .hdepend:
> /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h: \
>/usr/people/ralf/src/linux/linux/include/asm/mipsregs.h \
>/usr/people/ralf/src/linux/linux/include/asm/sn/addrs.h
> @touch
Ralf Baechle wrote:
From some random Linux source tree's .hdepend:
/usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h: \
/usr/people/ralf/src/linux/linux/include/asm/mipsregs.h \
/usr/people/ralf/src/linux/linux/include/asm/sn/addrs.h
@touch
Jamie Lokier writes:
.cvsignore
Not so fast. Read your .hdepend file, notice which files that it's
touching, and then notice that those are real source files
(include/linux/*.h and include/asm/*.h).
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Jamie Lokier wrote:
@touch /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/arch.h
[...]
.cvsignore
Oops, ignore me 'cos I obviously didn't read what I replied to.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, 12 Sep 2000, Ralf Baechle wrote:
On Mon, Sep 11, 2000 at 02:39:42PM -0700, Larry McVoy wrote:
On the other hand, if you do a
find . -type f | xargs touch
time cvs update .
it will melt down your DSL line for what seems forever. I killed it after
20 minutes, I have
Does *BSD run on S390?
Stephen Frazier
Oklahoma Department of Corrections
-Original Message-
On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:
I just thought I would remind all the nay-sayers that the *BSD world has
been doing something along this line since at least 1990. While some of
CC: trimmed to just l-k.
On Tue, 12 Sep 2000 10:02:59 +0200,
Ralf Baechle <[EMAIL PROTECTED]> wrote:
>From some random Linux source tree's .hdepend:
>
>/usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h: \
> /usr/people/ralf/src/linux/linux/include/asm/mipsregs.h \
>
On Mon, Sep 11, 2000 at 02:39:42PM -0700, Larry McVoy wrote:
> On the other hand, if you do a
>
> find . -type f | xargs touch
> time cvs update .
>
> it will melt down your DSL line for what seems forever. I killed it after
> 20 minutes, I have better things to do with my bandwidth.
Larry McVoy wrote:
> No matter what you do with rsync, there is no bloody way you can even
> come close to a single 32K disk read and then a 6K over the wire transfer.
> At least, I can't think of one, can you?
rsync will transfer a bunch of file modification times and, where they
don't match, a
On Mon, Sep 11, 2000 at 02:39:42PM -0700, Larry McVoy wrote:
On the other hand, if you do a
find . -type f | xargs touch
time cvs update .
it will melt down your DSL line for what seems forever. I killed it after
20 minutes, I have better things to do with my bandwidth. It's
CC: trimmed to just l-k.
On Tue, 12 Sep 2000 10:02:59 +0200,
Ralf Baechle [EMAIL PROTECTED] wrote:
From some random Linux source tree's .hdepend:
/usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h: \
/usr/people/ralf/src/linux/linux/include/asm/mipsregs.h \
On Mon, 11 Sep 2000, Horst von Brand wrote:
>
> mberglund <[EMAIL PROTECTED]> said:
>
> [...]
>
> > License:
> > This project will not be restricted to any one license. If a piece
> > of software is desirable, but under an Artistic-, BSD-, or even
> > GPL-style
mberglund <[EMAIL PROTECTED]> said:
[...]
> License:
> This project will not be restricted to any one license. If a piece
> of software is desirable, but under an Artistic-, BSD-, or even
> GPL-style license, it will be used, so long as it allows
> free(no cost)
l> If you can get me a tarball of the CVS repository, I'll import the
l> history into a BK tree and then we can do side by side tests.
I know BK is the best thing since sliced yams, but can you please take
this thread to some BK mailing list and do your performance
comparisons there?
On Mon, Sep 11, 2000 at 05:05:08PM -0700, Larry McVoy wrote:
> On Mon, Sep 11, 2000 at 06:49:43PM -0500, Jonathan Lemon wrote:
> > I don't know why I'm bothering to reply to this, but yes, if you're
> > trying to synchronize CVS source trees with only CVS, it will be slow.
> > Now, if you were to
On Mon, Sep 11, 2000 at 06:49:43PM -0500, Jonathan Lemon wrote:
> I don't know why I'm bothering to reply to this, but yes, if you're
> trying to synchronize CVS source trees with only CVS, it will be slow.
> Now, if you were to compare CVSup vs Bitkeeper, then things might get
> more
In article [EMAIL PROTECTED]> you write:
>On Mon, Sep 11, 2000 at 05:48:44PM -0500, Tony Mantler wrote:
>>
>> "It's the latency, stupid". I wouldn't care to argue whether CVS is slower
>> than BK or not, but consider that if you had a router between you and the
>> CVS server that was dropping
On Mon, Sep 11, 2000 at 07:44:52PM -0400, James Lewis Nance wrote:
> On Mon, Sep 11, 2000 at 03:45:18PM -0700, Larry McVoy wrote:
>
> > the 120MB for the checked out files and some mem for inodes. But the
> > difference in price is reasonable and if we have to buy memory for the
> > kernel
On Mon, Sep 11, 2000 at 03:45:18PM -0700, Larry McVoy wrote:
> the 120MB for the checked out files and some mem for inodes. But the
> difference in price is reasonable and if we have to buy memory for the
> kernel developers, we'll do it once we can afford to do it. It's _really_
> nice to
On Mon, Sep 11, 2000 at 05:48:44PM -0500, Tony Mantler wrote:
>
> "It's the latency, stupid". I wouldn't care to argue whether CVS is slower
> than BK or not, but consider that if you had a router between you and the
> CVS server that was dropping even 5% of your packets, or even just bumping
>
Note: trimmed the 390 list, they don't care according to Alan..
On Tue, Sep 12, 2000 at 12:21:16AM +0200, Jamie Lokier wrote:
> Larry McVoy wrote:
> > That's a benefit [for BK] of having changesets, I only need to compare
> > the ChangeSet file to know that 4 files were updated 2 were moved, and
At 5:13 PM -0500 9/11/2000, Larry McVoy wrote:
[...]
>> > > > over a 384Kbits/sec link.
>
>That's a 48Kbyte/sec link. Hardly a "horribly fast network". In fact,
>the bandwidth to FSMlabs.com and innominate.org seems to be identical,
>I suspect that my link is the bottleneck, not either of
David A. Gatwood wrote:
> > I'd love to see a filesystem feature where I could efficiently identify
> > "changed files", where "changed" is defined by last time this application
> > checked or something similar.
>
> An in-filesystem revision number would do the trick. Could be REALLY
>
> > Fourth, non-null pulls are similarly faster, again, by design. BK only
> > moves the data it needs to move. That means if you have a 100GB file
> > in which you have changed one byte, BK will move on the order of 1 byte
> > to update that file. And that's it - it doesn't compare the two
Larry McVoy wrote:
> We thought about this too (filesystems are where I got into kernel hacking),
> but dismissed it as a Linux only solution. As much as I'd like it to be
> otherwise, BK is not a Linux only product. Whatever we do needs to work on
> NT (shudder) as well as all the dinosaur
On Tue, 12 Sep 2000, Jamie Lokier wrote:
> I'd love to see a filesystem feature where I could efficiently identify
> "changed files", where "changed" is defined by last time this application
> checked or something similar.
An in-filesystem revision number would do the trick. Could be REALLY
On Mon, 11 Sep 2000, Larry McVoy wrote:
> That's a 48Kbyte/sec link. Hardly a "horribly fast network". In fact,
I meant FSMlabs, but yeah. ;-)
> Second of all, if you ask around, you'll find that I'm a performance guy
> more than anything and that I'm not given to skewing the numbers and
On Tue, Sep 12, 2000 at 12:24:26AM +0200, Jamie Lokier wrote:
> Larry McVoy wrote:
> > We have a hack in BK for this, at least I think we do, where we can look at
> > the time stamps to notice that you haven't modified the files. We don't
> > use it because of NFS screwing up timestamps. I
Larry McVoy wrote:
> We have a hack in BK for this, at least I think we do, where we can look at
> the time stamps to notice that you haven't modified the files. We don't
> use it because of NFS screwing up timestamps. I suppose we could enable
> it on a per repository basis so that if you
Larry McVoy wrote:
> That's a benefit [for BK] of having changesets, I only need to compare
> the ChangeSet file to know that 4 files were updated 2 were moved, and
> 5 were created, then I move those *portions* of those files across the
> wire.
What happens when I lose the ChangeSet file, or
On Tue, Sep 12, 2000 at 12:09:29AM +0200, Juan J. Quintela wrote:
> > "david" == David A Gatwood <[EMAIL PROTECTED]> writes:
> But I think that the null update is a "typical" usage, and more
> typical indeed a cvs diff (and how that it is spelled in bk). I want
> to be able to use cvs diff
On Mon, Sep 11, 2000 at 02:58:25PM -0700, David A. Gatwood wrote:
> > On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
> > > > Err, "faster"? The following is the moral equiv of 4 kernel updates
> > > > which had nothing to do using BitKeeper instead of CVS. The local copy
> > > >
> "david" == David A Gatwood <[EMAIL PROTECTED]> writes:
Hi
[stuff about unfair test]
I don't arguee if the test was fair or not.
david> and does not include a "null update", as that is an atypical usage pattern
david> for most trees that unfairly skews the test towards software or
Larry McVoy wrote:
> On the other hand, if you do a
>
> find . -type f | xargs touch
> time cvs update .
>
> it will melt down your DSL line for what seems forever. I killed it after
> 20 minutes, I have better things to do with my bandwidth. It's pretty
> clear that CVS is comparing
On Mon, 11 Sep 2000, Larry McVoy wrote:
>
> On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
> > > Err, "faster"? The following is the moral equiv of 4 kernel updates
> > > which had nothing to do using BitKeeper instead of CVS. The local copy
> > > was in San Francisco and the
On Mon, Sep 11, 2000 at 02:08:42PM -0700, Larry McVoy wrote:
>
> On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
> > > Err, "faster"? The following is the moral equiv of 4 kernel updates
> > > which had nothing to do using BitKeeper instead of CVS. The local copy
> > > was in San
On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
> > Err, "faster"? The following is the moral equiv of 4 kernel updates
> > which had nothing to do using BitKeeper instead of CVS. The local copy
> > was in San Francisco and the remote copy is Cort's machine in New Mexico
> > over
Larry McVoy wrote:
> > Development:
> > In addition, by maintaining the system in CVS we can offer much
> > faster and convenient source updates than are currently available
> > from other Linux-based systems currently available.
>
> Err, "faster"? The following is the
On Mon, 11 Sep 2000, Larry McVoy wrote:
>
> On Mon, Sep 11, 2000 at 01:13:56PM -0400, mberglund wrote:
> > Name:
> > Darkstar - an integrated operating system based on the Linux kernel
> > and a stable set of tools.
> [...]
> > Development:
> > In addition, by
On Mon, Sep 11, 2000 at 01:13:56PM -0400, mberglund wrote:
> Name:
> Darkstar - an integrated operating system based on the Linux kernel
> and a stable set of tools.
[...]
> Development:
> In addition, by maintaining the system in CVS we can offer much
> faster and
Name:
Darkstar - an integrated operating system based on the Linux kernel
and a stable set of tools.
Purpose:
To build a source based operating system that ties together the
Linux kernel and a stable set of standard tools. Essentially this
should bring
Name:
Darkstar - an integrated operating system based on the Linux kernel
and a stable set of tools.
Purpose:
To build a source based operating system that ties together the
Linux kernel and a stable set of standard tools. Essentially this
should bring
On Mon, Sep 11, 2000 at 01:13:56PM -0400, mberglund wrote:
Name:
Darkstar - an integrated operating system based on the Linux kernel
and a stable set of tools.
[...]
Development:
In addition, by maintaining the system in CVS we can offer much
faster and
Larry McVoy wrote:
Development:
In addition, by maintaining the system in CVS we can offer much
faster and convenient source updates than are currently available
from other Linux-based systems currently available.
Err, "faster"? The following is the moral equiv
On Mon, Sep 11, 2000 at 02:08:42PM -0700, Larry McVoy wrote:
On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
Err, "faster"? The following is the moral equiv of 4 kernel updates
which had nothing to do using BitKeeper instead of CVS. The local copy
was in San Francisco
On Mon, 11 Sep 2000, Larry McVoy wrote:
On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
Err, "faster"? The following is the moral equiv of 4 kernel updates
which had nothing to do using BitKeeper instead of CVS. The local copy
was in San Francisco and the remote copy
Larry McVoy wrote:
On the other hand, if you do a
find . -type f | xargs touch
time cvs update .
it will melt down your DSL line for what seems forever. I killed it after
20 minutes, I have better things to do with my bandwidth. It's pretty
clear that CVS is comparing
"david" == David A Gatwood [EMAIL PROTECTED] writes:
Hi
[stuff about unfair test]
I don't arguee if the test was fair or not.
david and does not include a "null update", as that is an atypical usage pattern
david for most trees that unfairly skews the test towards software or kernels
On Mon, Sep 11, 2000 at 02:58:25PM -0700, David A. Gatwood wrote:
On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
Err, "faster"? The following is the moral equiv of 4 kernel updates
which had nothing to do using BitKeeper instead of CVS. The local copy
was in San
On Tue, Sep 12, 2000 at 12:09:29AM +0200, Juan J. Quintela wrote:
"david" == David A Gatwood [EMAIL PROTECTED] writes:
But I think that the null update is a "typical" usage, and more
typical indeed a cvs diff (and how that it is spelled in bk). I want
to be able to use cvs diff for a whole
Larry McVoy wrote:
That's a benefit [for BK] of having changesets, I only need to compare
the ChangeSet file to know that 4 files were updated 2 were moved, and
5 were created, then I move those *portions* of those files across the
wire.
What happens when I lose the ChangeSet file, or
Larry McVoy wrote:
We have a hack in BK for this, at least I think we do, where we can look at
the time stamps to notice that you haven't modified the files. We don't
use it because of NFS screwing up timestamps. I suppose we could enable
it on a per repository basis so that if you knew
On Tue, Sep 12, 2000 at 12:24:26AM +0200, Jamie Lokier wrote:
Larry McVoy wrote:
We have a hack in BK for this, at least I think we do, where we can look at
the time stamps to notice that you haven't modified the files. We don't
use it because of NFS screwing up timestamps. I suppose we
On Mon, 11 Sep 2000, Larry McVoy wrote:
That's a 48Kbyte/sec link. Hardly a "horribly fast network". In fact,
I meant FSMlabs, but yeah. ;-)
Second of all, if you ask around, you'll find that I'm a performance guy
more than anything and that I'm not given to skewing the numbers and *if*
On Tue, 12 Sep 2000, Jamie Lokier wrote:
I'd love to see a filesystem feature where I could efficiently identify
"changed files", where "changed" is defined by last time this application
checked or something similar.
An in-filesystem revision number would do the trick. Could be REALLY
Fourth, non-null pulls are similarly faster, again, by design. BK only
moves the data it needs to move. That means if you have a 100GB file
in which you have changed one byte, BK will move on the order of 1 byte
to update that file. And that's it - it doesn't compare the two files,
David A. Gatwood wrote:
I'd love to see a filesystem feature where I could efficiently identify
"changed files", where "changed" is defined by last time this application
checked or something similar.
An in-filesystem revision number would do the trick. Could be REALLY
efficient. All
At 5:13 PM -0500 9/11/2000, Larry McVoy wrote:
[...]
over a 384Kbits/sec link.
That's a 48Kbyte/sec link. Hardly a "horribly fast network". In fact,
the bandwidth to FSMlabs.com and innominate.org seems to be identical,
I suspect that my link is the bottleneck, not either of theirs.
In
Note: trimmed the 390 list, they don't care according to Alan..
On Tue, Sep 12, 2000 at 12:21:16AM +0200, Jamie Lokier wrote:
Larry McVoy wrote:
That's a benefit [for BK] of having changesets, I only need to compare
the ChangeSet file to know that 4 files were updated 2 were moved, and
5
On Mon, Sep 11, 2000 at 05:48:44PM -0500, Tony Mantler wrote:
"It's the latency, stupid". I wouldn't care to argue whether CVS is slower
than BK or not, but consider that if you had a router between you and the
CVS server that was dropping even 5% of your packets, or even just bumping
the
On Mon, Sep 11, 2000 at 03:45:18PM -0700, Larry McVoy wrote:
the 120MB for the checked out files and some mem for inodes. But the
difference in price is reasonable and if we have to buy memory for the
kernel developers, we'll do it once we can afford to do it. It's _really_
nice to measure
On Mon, Sep 11, 2000 at 07:44:52PM -0400, James Lewis Nance wrote:
On Mon, Sep 11, 2000 at 03:45:18PM -0700, Larry McVoy wrote:
the 120MB for the checked out files and some mem for inodes. But the
difference in price is reasonable and if we have to buy memory for the
kernel developers,
In article local.mail.linux-kernel/[EMAIL PROTECTED] you write:
On Mon, Sep 11, 2000 at 05:48:44PM -0500, Tony Mantler wrote:
"It's the latency, stupid". I wouldn't care to argue whether CVS is slower
than BK or not, but consider that if you had a router between you and the
CVS server that
On Mon, Sep 11, 2000 at 06:49:43PM -0500, Jonathan Lemon wrote:
I don't know why I'm bothering to reply to this, but yes, if you're
trying to synchronize CVS source trees with only CVS, it will be slow.
Now, if you were to compare CVSup vs Bitkeeper, then things might get
more interesting.
On Mon, Sep 11, 2000 at 05:05:08PM -0700, Larry McVoy wrote:
On Mon, Sep 11, 2000 at 06:49:43PM -0500, Jonathan Lemon wrote:
I don't know why I'm bothering to reply to this, but yes, if you're
trying to synchronize CVS source trees with only CVS, it will be slow.
Now, if you were to
l If you can get me a tarball of the CVS repository, I'll import the
l history into a BK tree and then we can do side by side tests.
I know BK is the best thing since sliced yams, but can you please take
this thread to some BK mailing list and do your performance
comparisons there?
b
-
mberglund [EMAIL PROTECTED] said:
[...]
License:
This project will not be restricted to any one license. If a piece
of software is desirable, but under an Artistic-, BSD-, or even
GPL-style license, it will be used, so long as it allows
free(no cost)
On Mon, 11 Sep 2000, Horst von Brand wrote:
mberglund [EMAIL PROTECTED] said:
[...]
License:
This project will not be restricted to any one license. If a piece
of software is desirable, but under an Artistic-, BSD-, or even
GPL-style license, it will be
81 matches
Mail list logo
