Re: log-buf-len dynamic

[Eric W. Biederman]

Linus Torvalds <torvalds@xxxxxxxx> writes:

> On 25 Sep 2003, Eric W. Biederman wrote:
> > > 
> > > However, that only explains why you don't use BitKeeper. And everybody
> > > accepts that. When I started to use BK, I made it _very_ clear that
> > > service for non-BK users will be _at_least_ as good as it ever was before
> > > I started using BK.
> > 
> > And for the core kernel development this is true.  There are subprojects
> > that are currently using BK that you can't even get the code without
> > BK.  And the only reason they are using BK is they are attempting to
> > following how Linux is managed.  So having the Linux kernel
> > development use BK does have some down sides.
> 
> That's actually a pretty good point. I end up releasing "sparse" only as a
> BK archive, simply because I'm too lazy to care and there aren't enough
> people involved (and those that _are_ involved do actually end up
> re-exporting it as non-BK, but that doesn't invalidate your point).
>
> I don't know what the solution to it might be - but I don't think the 
> reason they are using BK is that they are trying to emulate "the great 
> kernel project". I know it wasn't for me - it's just that once you get 
> used to BK, there's no way you'll ever go back to CVS willingly. 

I expressed it badly.  But the kernel using BK both introduces people
to BK, and it validates BK as a useful tool.  Especially as the kernel
tends to embody many of the best practices in the community.

The only sure piece of the solution I have it to keep saying there is
a problem, and to raise the level of the conversation to it's
technical merits.

> > In addition there are some major gains to be had in standardizing on a
> > distributed version control system that everyone can use, and
> > unfortunately BK does not fill that position.
> 
> I don't disagree, but I don't see a real way to solve it. As Larry will 
> tell you, the technical problems are bigger than you imagine.  So a BK 
> killer won't be coming any time soon, methinks.

It does not have to start as a BK killer.  Just something that is
architecturally sound, once all of the basics work adding the polish
can be done by the community.

I am pretty certain I could write up something that got the core of
the repository right in a month or two.  The hard part is avoiding
mistakes in repository architecture.  CVS has never recovered, despite
a lot of good work put into it.  For the few blunders Larry has made
he has worked very hard to correct things.

But of course if I do something I won't be targeting the kernel
developers directly.  I will do it to solve my problems on the
projects I lead.  Which may not map well to kernel development.  But
doing anything else would be an academic exercise because I could
not maintain it.  

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/