Re: The direction linux is taking

[Larry McVoy]

On Thu, Dec 27, 2001 at 12:41:15PM -0800, Linus Torvalds wrote:
> No, I'm taking a bigger view. A patch is not just a "patch". A patch has a
> lot of stuff around it, one being the unknowable information on whether
> the sender of the patch is somebody who will do a good job maintaining the
> things the patch impacts.
> 
> That's something a source control system doesn't give you - but that
> doesn't mean that you cannot use a SCM as a tool anyway.

OK, cool, just checking.  We're on the same page.

> > I _think_ what you are saying is that an SCM where your repository is a
> > wide open black hole with no quality control is a problem, but that's
> > not the SCM's fault.  You are the filter, the SCM is simply an accounting/
> > filing system.
> 
> Right. But that's true only if I use SCM as a _personal_ medium, which
> doesn't help my external patch acceptance.
> 
> So even if I used CVS or BK internally, that's not what people _gripe_
> about.  People want write access, not just a SCM.

I think it is important to distinguish between BK and CVS.  CVS can't do 
what you want, BK can.

People can't have write access in CVS for the obvious reasons, the tree
becomes a chaotic mess of stuff that hasn't been filtered.  But in BK,
because each workspace is a repository, people inherently have write
access to *their* repository.  So they get SCM.  And they may eventually
get their stuff into your tree if you ever accept the changeset.

There are problems with this, BK isn't perfect, but it is much closer 
to solving the set of problems you are describing that CVS can ever 
hope to be.

> > but your typical SCM has the end user doing the merges, not the maintainer.
> > If you had an SCM system which allowed the maintainer to do all or some of
> > the merging, would that help?
> 
> Well, that's what the filesystem is for me right now ;)

Yes, and it works great for easy merges.  It sucks for complicated merges.
BK can help you a great deal with those merges.