On Sat, 1 May 1999, Jordan K. Hubbard wrote:
My suggestion would be to wait and see how bitkeeper pans out. Enough
people in the Linux camp have already looked at CVSup and gone ooh,
sexy! that I think there will already be significant pressure to
develop similar tools for the bitkeeper
On Wed, 5 May 1999, Brian Behlendorf wrote:
On Sat, 1 May 1999, Jordan K. Hubbard wrote:
My suggestion would be to wait and see how bitkeeper pans out. Enough
people in the Linux camp have already looked at CVSup and gone ooh,
sexy! that I think there will already be significant pressure
In article pine.bsf.4.10.9905051835560.388-100...@picnic.mat.net,
Chuck Robey chu...@picnic.mat.net wrote:
This discussion merits dropping, at least until someone rewrites
cvsup ctm. Don't hold your breath.
I haven't looked at bitkeeper, but I doubt anybody would have to
_rewrite_ CVSup.
In message 19990502015216.a...@keltia.freenix.fr Ollivier Robert writes:
: WHat are the improvements compared to Perforce ?
After working with Perforce for 9 month at Pluto, I'd have to say it
is head and shoulders above CVS. It is a different style of source
management, where you have to
In message pine.lnx.4.04.9905011928550.735-100...@feral.com Matthew Jacob
writes:
: Oh, very well, I'll have to say Perforce isn't that bad- it's just that it
: doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole
: branch and revision histories..
I've seen many Tk tools
RW == Robert Watson rob...@cyrus.watson.org writes:
RW So will bitkeeper provide a nice interface for migrating code
RW from an existing and well-established CVS repository to
RW whatever they use?
I've looked at bitkeeper and wonder what exactly are it's advantages
over CVS. It's
Matthew Jacob wrote...
Oh, very well, I'll have to say Perforce isn't that bad- it's just that it
doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole
branch and revision histories..
I know there's a reasonable web-based tool that lets you look at revision
histories for
On Fri, 30 Apr 1999, Kevin Day wrote:
To sum it all up is there any difference between the branches?
Yes. We hope that people like you will help us by participating in the
testing of potential releases _before_ they go out as releases, not
_afterwards_.
Sitting around
I honestly don't know when to bring up things like that, now. :)
For 3.2, _right_now_. What you're doing with Matt is the first stage;
the next involves bringing it back to the 3.2-beta tree and testing it
there.
Please understand that if you (the community) aren't working on this,
BitKeeper should be ready soon.
Once it's been proven stable, might it be a better alternative to CVS?
H
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
:BitKeeper should be ready soon.
:
:Once it's been proven stable, might it be a better alternative to CVS?
:
:H
Maybe, but we wouldn't know for a couple of years. You don't just go
trusting 15+ years worth of source history to a program that has just
barely been written. I think
On Sat, 1 May 1999, Matthew Dillon wrote:
#
#:BitKeeper should be ready soon.
#:
#:Once it's been proven stable, might it be a better alternative to CVS?
#:
#:H
#
# Maybe, but we wouldn't know for a couple of years. You don't just go
# trusting 15+ years worth of source history to a
#
#:BitKeeper should be ready soon.
#:
#:Once it's been proven stable, might it be a better alternative to CVS?
#:
#:H
#
# Maybe, but we wouldn't know for a couple of years. You don't just go
# trusting 15+ years worth of source history to a program that has just
#
-Original Message-
From: Matthew Dillon [mailto:dil...@apollo.backplane.com]
Sent: 01 May 1999 18:24
To: Harlan Stenn
Cc: Doug Rabson; Kevin Day; Mike Smith; da...@aps-services.com;
p...@originative.co.uk; freebsd-current@FreeBSD.ORG
Subject: Re: solid NFS patch #6 avail
So will bitkeeper provide a nice interface for migrating code from an
existing and well-established CVS repository to whatever they use?
I'm quite happy to allow them to test bitkeeper in a production
environment before using it in one myself, needless to say. :)
On Sat, 1 May 1999, Matthew
As I understand it, BitKeeper is indeed based on SCCS, and is a superset of
it. The performance hit of SCCS has been solved.
There are several significant commercial users of BitKeeper waiting for
the first production release, and Larry McVoy seems to be a bit of a maniac
when it comes to
: trusting 15+ years worth of source history to a program
: that has just
: barely been written. I think the Linux people are making
: a huge mistake
: by not using CVS.
:
:15 years? Our cvs repository is only about 5 years old and cvs isn't 15
:years old!
Well, ok, this
So will bitkeeper provide a nice interface for migrating code from an
existing and well-established CVS repository to whatever they use?
They have tools for RCS to SCCS- I dunno about CVS tho...
I'm quite happy to allow them to test bitkeeper in a production
environment before using it in
As I understand it, BitKeeper is indeed based on SCCS, and is a superset of
it. The performance hit of SCCS has been solved.
There are several significant commercial users of BitKeeper waiting for
the first production release, and Larry McVoy seems to be a bit of a maniac
when it comes
On Sat, 1 May 1999, Matthew Dillon wrote:
:BitKeeper should be ready soon.
:
:Once it's been proven stable, might it be a better alternative to CVS?
:
:H
Maybe, but we wouldn't know for a couple of years. You don't just go
trusting 15+ years worth of source history to a
:BitKeeper should be ready soon.
:
:Once it's been proven stable, might it be a better alternative to CVS?
:
:H
Maybe, but we wouldn't know for a couple of years. You don't just go
trusting 15+ years worth of source history to a program that has just
barely
On Sat, 1 May 1999, Matthew Jacob wrote:
:BitKeeper should be ready soon.
:
:Once it's been proven stable, might it be a better alternative to CVS?
:
:H
Maybe, but we wouldn't know for a couple of years. You don't just go
trusting 15+ years worth of source
I agree about CVS' limitations completely. I know that a lot of Linux
projects are under their own CVS control but what kind of history is
available for code once it reaches Linus? Does Linus have a CVS
repository which stores file-by-file history for the kernel?
No. That's what Bitkeeper
On Sat, 1 May 1999, Matthew Jacob wrote:
I agree about CVS' limitations completely. I know that a lot of Linux
projects are under their own CVS control but what kind of history is
available for code once it reaches Linus? Does Linus have a CVS
repository which stores file-by-file
That sounds like it would be time well spent. I like the sound of
Bitkeeper a lot. I just want someone else to test it :-).
You and everyone else!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Look- if Linux adopts Bitkeeper, you really should pay attention to that.
I doubt you'd find a more difficult set of software engineers to keep code
in sync for than the Linux folks- if Bitkeeper works for them and
essentially makes a rational release train for Linux, then a major
glaring
Look- if Linux adopts Bitkeeper, you really should pay attention to that.
I doubt you'd find a more difficult set of software engineers to keep code
in sync for than the Linux folks- if Bitkeeper works for them and
essentially makes a rational release train for Linux, then a major
Well, I'm not philosophically opposed to a clearly superior solution,
I simply don't want to see us make any moves which involve so many
messy trade-offs that we end up wasting more time embroiled in debate
than we save with the new tool.
My suggestion would be to wait and see how bitkeeper pans
Well, I'm not philosophically opposed to a clearly superior solution,
I simply don't want to see us make any moves which involve so many
messy trade-offs that we end up wasting more time embroiled in debate
than we save with the new tool.
My suggestion would be to wait and see how
According to Matthew Jacob:
Bitkeeper is a substantial improvement over CVS and Perforce. It's really
WHat are the improvements compared to Perforce ? I've begun looking at it and
if we forgot the Open Source argument (one that the FreeBSD project can't
forget), it is really a very nice SCM.
According to Harlan Stenn:
I'm mostly interested in the lines of development features, the ability
to check in various revisions of my *local* work, the ability to apply a
patch set as an atomic unit, and several of the GUI tools.
Perforce has all that.
--
Ollivier ROBERT -=- FreeBSD: The
Oh, very well, I'll have to say Perforce isn't that bad- it's just that it
doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole
branch and revision histories.. It doesn't have a 3-way filemerge tool (I
still fire up teamware (what NSElite became) to do heavy merging and use
The folks who did BitKeeper have a compare/contrast section in their web
page that talks about BitKeeper vs. CVS and Perforce.
http://www.bitkeeper.com
I'm running CVS at several places, and I'm going to try BitKeeper for a
couple of projects.
H
To Unsubscribe: send mail to
-Original Message-
From: Doug Rabson [mailto:d...@nlsystems.com]
Sent: 21 April 1999 20:14
To: Matthew Dillon
Cc: Peter Wemm; Matthew Reimer; freebsd-current@freebsd.org
Subject: Re: solid NFS patch #6 avail for -current - need
testers files)
I wonder if it would be too
Hello,
My name is David DeTinne and I have been suscribing to FreeBSD
Stable for some time now, before 2.2.2 was released.
Here is my view regarding your posting:
3.1 is probably the most unstable stable version ever to be sent out
by Walnut Creek. I have a machine that has 2.2.6 on it, which
To sum it all up is there any difference between the branches?
Yes. We hope that people like you will help us by participating in the
testing of potential releases _before_ they go out as releases, not
_afterwards_.
Sitting around doing nothing and then complaining after the fact
doesn't
On Fri, 30 Apr 1999 da...@aps-services.com wrote:
3.1 is probably the most unstable stable version ever to be sent out
by Walnut Creek. I have a machine that has 2.2.6 on it, which has
been abused, cold booted, etc. When I received 3.1 in the mail I
installed it on three seperate machines
To sum it all up is there any difference between the branches?
Yes. We hope that people like you will help us by participating in the
testing of potential releases _before_ they go out as releases, not
_afterwards_.
Sitting around doing nothing and then complaining after the fact
I honestly don't know when to bring up things like that, now. :)
For 3.2, _right_now_. What you're doing with Matt is the first stage;
the next involves bringing it back to the 3.2-beta tree and testing it
there.
Please understand that if you (the community) aren't working on this,
nobody
On Fri, 30 Apr 1999, Mike Smith wrote:
To sum it all up is there any difference between the branches?
Yes. We hope that people like you will help us by participating in the
testing of potential releases _before_ they go out as releases, not
_afterwards_.
Sitting around doing nothing
Brian Feldman wrote:
I just wish april would go away, very, very fast...
Here's a challenge to help you get by the rest of the days, figure out
how to write my name, in its original form I was given at birth :-)
Hmm... is it cheating to use Hiragana? (^_^)
Being a chinese name (I
Previously on Wed, Apr 21, 1999 at 12:31:03PM -0700, Matthew Dillon wrote:
:
: I think the existing release schedule is pretty good. Any faster and
: we might as well not have two branches at all. We really need a
: -current branch in order to make and test radical changes, and the
This is the only thing stopping me from upgrading our production machines
to 3.1-STABLE.
Please, please, please backport these fixes!
I have to echo these feelings. NFS, as both server and client, is
working without noticeable problems for us under the old 2.2-stable.
I am afraid of
People desperate for current functionality can wait, back port themselves or
run current. I have taken all three options in the past :-)
I agree. I have recently installed 3.1-STABLE on two machines, and in
each case the ethernet drivers (xl and lnc) had been broken since 3.1
(both are now
On Thu, 22 Apr 1999, Daniel Eischen wrote:
I have to echo these feelings. NFS, as both server and client, is
working without noticeable problems for us under the old 2.2-stable.
I am afraid of upgrading to 3.1-stable with the reported NFS problems,
and we can't get by without NFS.
I was
Steve Kargl wrote:
That's a little foolish since we've still not found all the egcs
optimizer bugs and whatnot; didn't you guys see the one Luigi found
the other day for ftpd? Now *that* had to be some obscure debugging
work! :-)
Clearly, that goes to show Luigi must have no
Steve Kargl wrote:
That's a little foolish since we've still not found all the egcs
optimizer bugs and whatnot; didn't you guys see the one Luigi found
the other day for ftpd? Now *that* had to be some obscure debugging
work! :-)
Clearly, that goes to show Luigi must
On Thu, 22 Apr 1999, Luoqi Chen wrote:
Steve Kargl wrote:
That's a little foolish since we've still not found all the egcs
optimizer bugs and whatnot; didn't you guys see the one Luigi found
the other day for ftpd? Now *that* had to be some obscure debugging
work! :-)
On Tue, 20 Apr 1999, Matthew Dillon wrote:
NFS patch #6 is now available for -current. This patch has been
extensively tested with NFS and with FFS+softupdates and has not
screwed up yet, so I'm reasonably confident that it will not
scrap whole filesystems :-)
Great work guys! It almost seems that -current is more stable than
-stable!
Matt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
:2 questions I had:
:
:1) you said you disabled partial writes that were causing these
:mmap() problems, they were causing problems because NFS had to
:muck with the structures directly in order to do zero copy?
: so if our NFS impelementation didn't do that it wouldn't be
:an issue probably.
Matthew Reimer wrote:
Great work guys! It almost seems that -current is more stable than
-stable!
Matt
Funny you should mention it. I've heard this from a number of people over
the last week.. One has even suggested using a particular known-good 4.0
snapshot in preference to a 3.1-stable
On Wed, 21 Apr 1999, Matthew Dillon wrote:
:2 questions I had:
:
:2) at BAFUG 2 or 3 months ago I, *cough* attempted to keep up with you
:an Julian talking about VM issues. :) Something you guys brought up
:was problems with mmap() + read()/write() no staying in sync and requireing
:an
Peter Wemm once wrote:
Great work guys! It almost seems that -current is more stable than
-stable!
Funny you should mention it. I've heard this from a number of people
over the last week.. One has even suggested using a particular
known-good 4.0 snapshot in preference to a 3.1-stable for
:Matthew Reimer wrote:
: Great work guys! It almost seems that -current is more stable than
: -stable!
:
: Matt
:
:Funny you should mention it. I've heard this from a number of people over
:the last week.. One has even suggested using a particular known-good 4.0
:snapshot in preference to a
On Thu, 22 Apr 1999, Peter Wemm wrote:
Matthew Reimer wrote:
Great work guys! It almost seems that -current is more stable than
-stable!
Matt
Funny you should mention it. I've heard this from a number of people over
the last week.. One has even suggested using a particular
Matthew Reimer wrote:
Great work guys! It almost seems that -current is more stable than
-stable!
Matt
Funny you should mention it. I've heard this from a number of people over
the last week.. One has even suggested using a particular known-good 4.0
snapshot in preference to a
On Wed, 21 Apr 1999, Matthew Dillon wrote:
:Matthew Reimer wrote:
: Great work guys! It almost seems that -current is more stable than
: -stable!
:
: Matt
:
:Funny you should mention it. I've heard this from a number of people over
:the last week.. One has even suggested using a
:I wonder if it would be too radical to suggest that the release cycle for
:4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets
:worse and worse as time goes on and it just becomes a waste of programmer
:time. If we are reasonably careful with the 4.0 tree, I think a 4.0
On 21-Apr-99 Matthew Dillon wrote:
Most of the bug fixes have been backported to -stable. Getting the new
VM system into -stable ( which I want to do just after the 3.2 release )
is going to require brute force, though. Unfortunately, the most recent
fixes to NFS fall into
On Wed, 21 Apr 1999, Matthew Dillon wrote:
:I wonder if it would be too radical to suggest that the release cycle for
:4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets
:worse and worse as time goes on and it just becomes a waste of programmer
:time. If we are reasonably
:Speaking of, when can we expect to see this wonderfull _stability_
:improvement in -stable? I'm setting up a server here, and would
:rather have fixed NFS code in it... Yet, jumping to -current is
:officially wrong... Thanks!
:
: -mi
Well, you already see a lot of the pure bug fixes
At 01:09 PM 4/21/99 -0700, Matthew Dillon wrote:
:Speaking of, when can we expect to see this wonderfull _stability_
:improvement in -stable? I'm setting up a server here, and would
:rather have fixed NFS code in it... Yet, jumping to -current is
:officially wrong... Thanks!
:
: -mi
:Hi,
:Just wondering if these changes also have the side effect of fixing the
:nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99
:
:
:The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing
:the file, but then it does some really weird crap when
Speaking of upgrading to -current from 3.x-STABLE, I was just wondering --
does the new EGCS imply that things like apps2go Motif won't link properly
against a 4.x-CURRENT world now? It's things like this that will hold me
back, if they indeedy are a problem.
Brian
To Unsubscribe: send mail
At 01:29 PM 4/21/99 -0700, Matthew Dillon wrote:
:Hi,
:Just wondering if these changes also have the side effect of fixing the
:nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99
:
:
:The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing
:the file,
Hi,
At 4:34 pm -0700 20/4/99, Matthew Dillon wrote:
NFS patch #6 is now available for -current.[etc]
Looks real good here. Been running two servers continuously building the
world with their /usr/obj cross-mounted on each other. Oh, and one of them
is SMP running -j8.
Great job!
--
Bob
I'm curious, is there any plan to backport egcs to -stable or no?
No.
Also, as a side note: good thing we went with egcs, as it was just
announced that egcs is now the official gcc.
Yep, I had some inside info that this was probably going to happen.
--
-- David(obr...@nuxi.com -or-
Funny you should mention it. I've heard this from a number of people over
the last week.. One has even suggested using a particular known-good 4.0
snapshot in preference to a 3.1-stable for a production system..
That's a little foolish since we've still not found all the egcs
optimizer
Speaking of, when can we expect to see this wonderfull _stability_
improvement in -stable? I'm setting up a server here, and would
Usually when we're sure it's not a pessimization in other ways. I
think people are getting just a bit prematurely excited here, not to
knock Matt's good work or
I wonder if it would be too radical to suggest that the release cycle for
4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets
worse and worse as time goes on and it just becomes a waste of programmer
time. If we are reasonably careful with the 4.0 tree, I think a 4.0
I'm curious, is there any plan to backport egcs to -stable or no? Also, as a
There are no plans at this time to merge egcs over. This will only
happen if time and hindsight prove egcs to be of low enough
impact that it's suitable -stable material.
- Jordan
To Unsubscribe: send mail to
All I'm saying (I think) is that we shouldn't allow the 4.0 release cycle
to stretch out to 2 years like the 3.0 cycle did (discounting 3.0 as a
beta release).
No argument there - the current schedule is 12 months for 4.0. 2
years far too long and merely the result of unforseen delays and
Jordan K. Hubbard wrote:
Funny you should mention it. I've heard this from a number of people over
the last week.. One has even suggested using a particular known-good 4.0
snapshot in preference to a 3.1-stable for a production system..
That's a little foolish since we've still
Daniel C. Sobral wrote:
Jordan K. Hubbard wrote:
Funny you should mention it. I've heard this from a number of people over
the last week.. One has even suggested using a particular known-good 4.0
snapshot in preference to a 3.1-stable for a production system..
That's a
Luigi is an interesting spelling of Louqi.
Or even Luoqi, as his name is actually spelled. :-)
Sorry, Mr. Chen, for the transposition of you and Luigi. Temporary
brain fade! :)
The bug was actually in libalias.
Yes, also correct.
- Jordan
To Unsubscribe: send mail to
: Speaking of, when can we expect to see this wonderfull _stability_
: improvement in -stable? I'm setting up a server here, and would
:
:Usually when we're sure it's not a pessimization in other ways. I
:think people are getting just a bit prematurely excited here, not to
:knock Matt's good work
: work! :-)
:
: Clearly, that goes to show Luigi must have no life... :-)
:
:
:Luigi is an interesting spelling of Louqi.
:
:The bug was actually in libalias.
:
:--
:Steve
Luoqi found a bug in the compiler's optimizer. I presume someone
has/will commit a change to libalias to work
Matthew Dillon wrote:
: work! :-)
:
: Clearly, that goes to show Luigi must have no life... :-)
:
:
:Luigi is an interesting spelling of Louqi.
Whoops! Luoqi ;-)
:The bug was actually in libalias.
:
Luoqi found a bug in the compiler's optimizer. I presume someone
:Just wondering if these changes also have the side effect of fixing the
:nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99
:
:The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing
:the file, but then it does some really weird crap when dealing
I was just wondering -- does the new EGCS imply that things like
apps2go Motif won't link properly against a 4.x-CURRENT world now?
My Apps2go Motif works just file post-EGCS.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with
What does this patch fix?
Tnks!
Amancio
--
Amancio Hasty
ha...@star-gate.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
On Tue, 20 Apr 1999, Amancio Hasty wrote:
What does this patch fix?
NFS clients getting blocks of 0x00 in the cache.
try to link a large object over NFS without the patches, you'll see
what i mean.
Matt, i'm going to test your patches now, I really appreciate the work
and explanations you've
:
:Matt, i'm going to test your patches now, I really appreciate the work
:and explanations you've given as to the problem and the solution you've
:devised. If anyone's gonna find a NFS bug :)
:
:I'm impressed with the changes you're proposing for the VM system
:and was wondering if these
:What does this patch fix?
:
: Tnks!
: Amancio
:
: Amancio Hasty
: ha...@star-gate.com
It mainly fixes interactions between mmap(), read(), and write() on
NFS files. Many utilities ( such as the compiler/linker ) these days
use a combination of the three and NFS was
85 matches
Mail list logo
