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 cop
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
Ne
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 offe
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, a
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 this
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 t
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
th
On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:
> 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 yo
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 mi
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
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
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 /usr/people/ralf/src/li
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 \
> /usr/people/ralf
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, 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,
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) d
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?
htt
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 interesting.
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 eve
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 devel
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 meas
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
> t
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 theirs
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
> > 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 fil
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 Unix
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
eff
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 *i
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 supp
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
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 mis
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 fo
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
> > > > w
> "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 re
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 01:39:16PM -0500, Troy Benjegerdes wrote:
> Cool... So can the latest version of the sources for BitKeeper be checked
> out too, or do we just have to write a script to extract it from the BkWeb
> changesets? :P
We're working on the docs for the 2.0 release. You can get t
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 a
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 mo
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 maintaining
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
45 matches
Mail list logo
