[lkml]   [2002]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Bitkeeper change granularity (was Re: A modest proposal -- We need a patch penguin)
On Fri, Feb 01, 2002 at 06:45:59PM -0500, Rob Landley wrote:
> > The norm is:
> > clone a repository
> > edit the files
> > modify/compile/debug until it works
> > check in
> > push the patch up the shared repository
> > I'm really at a loss as to why that shouldn't be the norm here as well.
> You'll notice that bitkeeper is totally useless between the clone and the
> check in, in your model. It can't really be used DURING development, only
> before and after.

What nonsense. Go read the docs.

> As for a simple example of when your model above breaks down, a lot of
> developers who use things like emacs have their source control system as part
> of their integrated development environment. When they "save and compile",
> it's checked into the RCS (often with a terse three or four word comment
> that's intended as a label to jog the developer's memory).

Hey genuis. Download BK, install it, get into emacs, and type the key
strokes you just described. What happens? I'll let you in on a little
secret, smart boy, it does exactly what it should do. Works just like
it were RCS or SCCS. It was carefully designed behave exactly like SCCS
so that emacs/make/patch/etc all just know how to use it. Try patching
a BK repository w/ patch(1) and you'll see

retrieve file from revision system with lock?

Just works. Fits neatly with the tools that we all know and love.

So explain to me again how it is that the tool is "totally useless"
when it works *exactly* the way you say it should?
Larry McVoy lm at
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.293 / U:0.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site