Re: kernel.bkbits.net off the air

[Larry McVoy]

On Thu, Nov 13, 2003 at 07:17:11PM +0000, Andrew Walrond wrote:
> And I still maintain that a stripped out, redistributable, clone/pull only 
> binary tool without the restrictive license would be a real smart business 
> move.

I'm trying to see why.

Our commercial customers don't care about this so there isn't any business
incentive there.

The actual BK users don't care about this, they use BK.

The BK detractors aren't going to touch anything that we produce, they are 
convinced we're out to do them harm somehow.

So who's left?

And a better question is why doesn't some open source person do this?  All 
you need to do is create a network daemon which responds to clone requests
and pull requests.  The clone request sends across a tarball and the client
side untars it.  The pull request sends a changeset key (which was sent in
the last clone/pull) and gets a tarball of new/changed files, the new 
top of trunk changeset key, and a list of renames.  Actually the easier way
is to do it more like diff does, for each file that has been changed, send
across a "delete this file and any directories the deletion leaves empty"
list, and then you unpack the tarball on top of the tree.

This would be easy to build but I don't see it solving anything.  All it
does is act as a replacement for rsync.  It doesn't have revision history,
you can't do diffs, etc.  As soon as this exists, people will ask you
for all the other features.  Which is why I don't want to build it, I
don't want to get sucked into the "please rebuild BK as a GPLed product"
business.

What am I missing?
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm
-
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/