What are the reasons that Linux isn't kept in an CVS repository? I
mean, it would still give Linus full control over his branch of the
kernel, and it would make merging of Alan's branches into the main
branch easier.
Additionally, a BTS for the kernel would be nice. But this would be
difficult because many modules are developed as separate projects,
right?
Jens M?ller wrote:
>
> What are the reasons that Linux isn't kept in an CVS repository?
Linus -is- CVS, cvs with a brain. :)
A first step is setting up CVS and BK repositories on kernel.org which
contain the patches Linus publishes, something which I'm working on.
After that, we'll see how annoying/useful Linux in a sccs is, and if
Linus is interested in committing directly to them.
Historically Linus and Alan (IMHO rightly so) have ignored CVS because
of its many shortcomings. subversion and BK are promising, though.
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
In article <[email protected]> you wrote:
> What are the reasons that Linux isn't kept in an CVS repository?
Some architectures and branches are kept in Source control. Like sparc, xfs.
Also the complete kernel is available in bitkeeper. Linux does not see a
reason to have his version in the CVS. And since he is the only commiter it
is quite valid for him to choose the tool he wants to use.
> mean, it would still give Linus full control over his branch of the
> kernel, and it would make merging of Alan's branches into the main
> branch easier.
It is is not your problem to merge them. Alan and Linus are doing that. And
they are fine without CVS.
BTW: this discussion is very old, you should only start it, if you have new
facts :)
Greetings
Bernd
(I'm the BitKeeper guy in case someone doesn't know.)
On Sun, Nov 04, 2001 at 05:24:37AM +0100, Bernd Eckenfels wrote:
> Some architectures and branches are kept in Source control. Like sparc, xfs.
> Also the complete kernel is available in bitkeeper. Linux does not see a
> reason to have his version in the CVS. And since he is the only commiter it
> is quite valid for him to choose the tool he wants to use.
Linus has toyed with using BitKeeper but has always found some fault with
it (we're not complaining, we tend to agree with his complaints and fix
them as fast as we can). It's still not as good as he wants so I'm not
sure if he'll take it for a spin for 2.5 or not.
> It is is not your problem to merge them. Alan and Linus are doing that. And
> they are fine without CVS.
One thing we have been doing is working on merge tools. Some of our users
have really nasty merge problems and need better merge technology. We've
come up with something that we think is very good. You can see a screen
shot at
http://www.bitkeeper.com/gifs/fm3new.gif
and if you'd like to take it for a test drive, we've put up just the stuff
you need at
http://www.bitkeeper.com/promerge.tgz
You don't need BitKeeper installed to run it, but if you do then as you move
through the diffs, the checkin comments for the affected lines will show
up in the top two windows (very handy when you are scratching your head and
wondering why did someone change this).
It takes a little getting used to and it could sure use some docs, but we
have compared this to other graphical merge tools out there and think we
have the best of the lot. It takes advantage of some unique information
we can extract from the data in the revision control system; unless you
have a very similar revision engine, it's impossible to do as well as we
do. And for you poor PPC BK guys, yeah, we know that the original merge
tool sucked. You'll like this better.
Anyway, getting back to Linus & Co, and for that matter, open source
efforts in general, they typically have a somewhat different model
than BK. In BK today, before you can push up a change you have to merge
it with whatever is in the tree to which you are sending the change.
In other words, each user merges rather than the maintainer. We're well
aware that not everyone likes this model so we're working on a small set
of changes so that users can push their changes to the maintainer and the
maintainer merges them. This makes merge tools even more important to
the maintainers, so if you give the filemerge a try and have suggestions
for improvements, we'd love to hear them.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Nov 03, 2001 at 09:56:34PM -0800, Larry McVoy wrote:
> and if you'd like to take it for a test drive, we've put up just the stuff
> you need at
>
> http://www.bitkeeper.com/promerge.tgz
>
> You don't need BitKeeper installed to run it
Andrew Pimlott politely pointed out that this isn't true, and here's the fix:
tar zxf promerge.tgz
cd promerge
cat > bk
exit 0
^D
chmod +x bk
PATH=$PATH:$PWD ./RUN_ME
Sorry about that.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
