RE: Subversion use for Kernel work

Without having read the rest of this thread here yet, I would like to say
that this is, IMHO, a mis-representation of the discussion on the kernel
lists.

Several ppl on lkml have voiced their opinions on SVN, but to the best of my
knowledge Linus has not recently said anything about it. A year ago, when he
chose BitKeeper, he thought SVN was not good enough yet for what he wanted
from an SCM system.

I have not seen since then any comments from *HIM* that he is considering to
use SVN instead of BitKeeper, or indeed that he is considering to use
anything else at this moment.

So I don't think that there's any opportunity at all, at the moment.

Besides, I doubt that SVN is already ready for such a task, but who knows, I
might be wrong on that one :-)

With regards,

--Tim

-----Original Message-----
From: Bob Gustafson [mailto:bobgus@rcnChicago.com]
Sent: woensdag 26 februari 2003 17:20
To: dev@subversion.tigris.org
Subject: Subversion use for Kernel work

There is a rather fascinating read at:

http://kt.zork.net/kernel-traffic/latest.html

(February 23 issue - might not be 'latest' in a few days)

Some excerpts are given further below.

The kernel is being kept in BitKeeper, which is a proprietary system, but
the proprietors have given free use to kernel developers. This grates on a
number of open source developers and from time to time (now for example), a
flame war erupts over the issue. (But you guys know all that already)

At the moment, there does exist an opportunity for the Subversion community
to make a full court press on getting subversion adopted for kernel use.

If it is ready.

BobG

===== Kernel Traffic excerpts below ======

Andrea liked the 'Binglish' comparison, but said:

...
      After we can reach the data we can use any version control system
we want to manage it, I'm going to write MORE STUPID scripts to do that.
I'm been told of several giga archives with dozen thousand revisions under
subversion for istance (I know Al Viro blamed subversion code but if the
design it's good it may be a good start). subversion may not have all the
features
of bitkeeper but we can certainly add them over time, the only thing it
matters to me is that we get rid of being forced to use a proprietary
protocol to fetch the data.

      The kernel CVS in more than enough for my/our needs and I thank
Larry for seeing it was necessary to allow the kernel data to be open. Now
there's no reason to argue anymore with Larry or Linus, they can choose
what they can legally use and we can choose what we can legally use and
what we find more productive in the long run. I really believe in open
protocols and open source software being superior and a necessary thing in
the long run, it's not that I advocate people to use open source products
and then I change my mind and I run proprietary apps to develop the kernel
(I don't put a smile here because clearly this isn't an obvious thought).

----
And Henning P. Schmiedehausen also said to Larry:
      Linus stated in public that he was/is unhappy with CVS. Without
Bitkeeper he might use Subversion today. But by using Bitkeeper he made it
possible that you and your company started using him as your posterboy for
the "SCM good enough for Linus Torvalds to use". This is IMHO not correct.
BK is just "the first SCM which came along and was good enough for Linus
Torvalds to use it".
      I do remember Linus saying that he wants to try out BitKeeper for
the 2.5 development tree and if it does  not work out, switch to something
else in the 2.6, 2.7... cycle.
      The rift that the whole BitKeeper/BitMover stuff has opened in the
kernel developer community IMHO justifies such a step forward . I'd like to
see SVN to be used as an alternative tool. Not because it is better (it
probably is not, but I haven't had a chance to try out BK because I don't
qualify for the free license) than BK but because it has no strings
attached to its usage.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org