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 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
#
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
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
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
21 matches
Mail list logo
