[BK] upgrade will be needed

[BK] upgrade will be needed

[Larry McVoy]

This is a heads up that the BK tree for the kernel is currently at 59,000
changesets give or take a few.  The BK that you are using uses unsigned
shorts for the internal names of each delta which means you folks are
about 100 days away from things no longer working.

The good news is that the openlogging tree for the kernel has 135,000
changesets so we've obviously long since fixed this problem.

The bad news is that you will need to upgrade your BK binary in order
to pass over the 64K changeset boundary.  The data is stored on disk in
ascii so it doesn't matter if you upgrade until you hit the problem but
sooner or later you will need to upgrade.

We'll get the fix into bk-3.2.4 which should be out by the end of the
month.  When we release that we'll send out notice and it would be good
if people gave it a try and let us know if they hit issues because in a
couple of months everyone is going to have to upgrade.

It's possible that we'll be changing the BK license to conform more with
our commercial license but we won't do that without running it by Linus &
Co to make sure that it's acceptable.  One change we'd like to make there
is to clarify the non-compete stuff.  We've had some people who have
indicated that they believed that if they used BK they were agreeing
that they would never work on another SCM system.  We can see how it
is possible that people would interpret the license that way but that
wasn't our intent.  What we would like to do is change the language to
say that if you use BK you are agreeing that you won't work on another
SCM for 1 year after you stop using BK.  But after that you would be
able to hack on anything that you wanted.  That was more of what we
had in mind in the first place but we didn't make it clear.  If you all
thought that using BK meant you had no right to hack on SCM ever again,
that's just not fair.  We need to protect our IP but you should have
the right to choose to go hack SCM if that's what you (our first choice
is that you came and worked here, we really like kernel hackers, but if
you don't want to that's cool too).
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[Matthew Jacob]

I'm curious why you'd have a non-compete for 1 year for just using BK.
That would make BK more or less unique amongst packages, no?

Re: [BK] upgrade will be needed

[Adam Sulmicki]

On Sun, 13 Feb 2005, Matthew Jacob wrote:

> I'm curious why you'd have a non-compete for 1 year for just using BK.

Larry likes to participate in flamewars on LKML ? :-)

> That would make BK more or less unique amongst packages, no?

Re: [BK] upgrade will be needed

[Geert Uytterhoeven]

On Sun, 13 Feb 2005, Larry McVoy wrote:
> wasn't our intent.  What we would like to do is change the language to
> say that if you use BK you are agreeing that you won't work on another
> SCM for 1 year after you stop using BK.  But after that you would be

Hypothetical question (for me, since I don't use BK right now): What if my
employer wants to put me on an SCM-project next month?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [BK] upgrade will be needed

[Bartlomiej Zolnierkiewicz]

On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy <lm@bitmover.com> wrote:
> is to clarify the non-compete stuff.  We've had some people who have
> indicated that they believed that if they used BK they were agreeing
> that they would never work on another SCM system.  We can see how it
> is possible that people would interpret the license that way but that
> wasn't our intent.  What we would like to do is change the language to

I always interpreted it the other way, that if I start working on other
SCM I should stop using BK.

> say that if you use BK you are agreeing that you won't work on another
> SCM for 1 year after you stop using BK.  But after that you would be

I don't even plan working on some SCM system, but being
tainted for 1 year for just *using* BK is not worth the price IMHO.

Regards,
Bartlomiej

Re: [BK] upgrade will be needed

[Jeff Sipek]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

On Mon, Feb 14, 2005 at 01:08:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy <lm@bitmover.com> wrote:
> > is to clarify the non-compete stuff.  We've had some people who have
> > indicated that they believed that if they used BK they were agreeing
> > that they would never work on another SCM system.  We can see how it
> > is possible that people would interpret the license that way but that
> > wasn't our intent.  What we would like to do is change the language to
> > say that if you use BK you are agreeing that you won't work on another
> > SCM for 1 year after you stop using BK.  But after that you would be
> 
> I don't even plan working on some SCM system, but being
> tainted for 1 year for just *using* BK is not worth the price IMHO.

I agree, the price is just too high. No matter how much I like BK, I
would give it up.

Jeff.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 10:08:20AM -0500, Jeff Sipek wrote:
> On Mon, Feb 14, 2005 at 01:08:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy <lm@bitmover.com> wrote:
> > > is to clarify the non-compete stuff.  We've had some people who have
> > > indicated that they believed that if they used BK they were agreeing
> > > that they would never work on another SCM system.  We can see how it
> > > is possible that people would interpret the license that way but that
> > > wasn't our intent.  What we would like to do is change the language to
> > > say that if you use BK you are agreeing that you won't work on another
> > > SCM for 1 year after you stop using BK.  But after that you would be
> > 
> > I don't even plan working on some SCM system, but being
> > tainted for 1 year for just *using* BK is not worth the price IMHO.
> 
> I agree, the price is just too high. No matter how much I like BK, I
> would give it up.

The way some people are reading the license the price is even higher,
they think it is a forever tainted license as it stands today.  I've had
specific requests to clarify this part of the license.

So how would you suggest that we resolve it?  The protection we need is
that people don't get to

    - use BK
    - stop using BK so they can go work on another system
    - start using BK again
    - stop using BK so they can go work on another system
    ...

We could say that if you stop using BK and work on another system then
you can't ever use it again.  We're not going to do that, we've already
had to calm the fears of people who found themselves in that situation
for their job.  

So what do you want us to do?  This isn't a change to take stuff from
you, it's a change that some of your peers asked us to do so they could
use BK (and it would be nice if the people who wanted this are reading
this thread and will speak up so it doesn't look like I'm making it up).

What we've been doing so far is telling people who were worried to act as
if there were a year long gap and they have been happy with that answer
but they are asking for us to put it in the license so they don't have
to depend on some email based side agreement.

It would be nice if you could talk this over amongst yourselves and
suggest an answer.  I can see why you think it is a bad change, I'm hoping
that you can see why other people may want us to make this sort of change.
Maybe if you think about it a bit you'll come up with a better solution.
Or maybe we will.  Either way, I can't be very involved in the process,
I'm taking off for a week long vacation starting Wednesday and I won't
have email access.  Which will be a good way to make sure that if this 
turns into a flame war I won't be prolonging it.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[linux-os]

On Mon, 14 Feb 2005 lm@bitmover.com wrote:

> On Mon, Feb 14, 2005 at 10:08:20AM -0500, Jeff Sipek wrote:
>> On Mon, Feb 14, 2005 at 01:08:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
>>> On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy <lm@bitmover.com> wrote:
>>>> is to clarify the non-compete stuff.  We've had some people who have
>>>> indicated that they believed that if they used BK they were agreeing
>>>> that they would never work on another SCM system.  We can see how it
>>>> is possible that people would interpret the license that way but that
>>>> wasn't our intent.  What we would like to do is change the language to
>>>> say that if you use BK you are agreeing that you won't work on another
>>>> SCM for 1 year after you stop using BK.  But after that you would be
>>>
>>> I don't even plan working on some SCM system, but being
>>> tainted for 1 year for just *using* BK is not worth the price IMHO.
>>
>> I agree, the price is just too high. No matter how much I like BK, I
>> would give it up.
>
> The way some people are reading the license the price is even higher,
> they think it is a forever tainted license as it stands today.  I've had
> specific requests to clarify this part of the license.
>
> So how would you suggest that we resolve it?  The protection we need is
> that people don't get to
>
>    - use BK
>    - stop using BK so they can go work on another system
>    - start using BK again
>    - stop using BK so they can go work on another system
>    ...


What??? Why not? BK is a PROGRAM. You can't tell somebody
that once they use some program in one job, they can't
use it again. What kind of "protection" are you claiming?

Would you think that IBM could restrict persons who
learned FORTRAN to never use FORTRAN again should they
change jobs? Or that they need to wait some time-limit?


Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: [BK] upgrade will be needed

[Larry McVoy]

> >So how would you suggest that we resolve it?  The protection we need is
> >that people don't get to
> >
> >   - use BK
> >   - stop using BK so they can go work on another system
> >   - start using BK again
> >   - stop using BK so they can go work on another system
> 
> What??? Why not? BK is a PROGRAM. You can't tell somebody
> that once they use some program in one job, they can't
> use it again. What kind of "protection" are you claiming?

It is a program that comes with a license.  Licenses have terms which
survive the termination of the license, that's industry standard, they
all have such terms.

In this case the situation is unusual because we have a program that is
ahead, in some ways, of all the other programs out there that do the
same thing.  We'd like to protect that lead.  We put that lead at risk
by giving you BK for free, that's more or less suicide because the open
source world has a long track record of copying that which they find
useful.  We don't want you to copy it.  If you can't agree to not copy
it then you don't get to use it in the first place.

This is not that weird people, people sign NDA's which are far more
draconian every day.  Read any software license, they all have the
non-compete as well, they hide it in the reverse engineering restriction.
Those licenses don't care if you are competing with them or not, they
do a blanket do-not-reverse-engineer no matter who you are.  We tried
to be specific so that we were restricting the tiny subset of the world
that wants to hack SCM, not everyone else.  Because that's different
than standard language we get screamed at.  What you aren't figuring
out is that the standard language is more restrictive, not less.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[Pavel Machek]

Hi!

> Those licenses don't care if you are competing with them or not, they
> do a blanket do-not-reverse-engineer no matter who you are.  We
> tried

Your license is way worse than standard do-not-reverse-engineer. Put
standard do-not-reverse-engineer there and you'll see the screams
going down...

But I do not think you can prevent anyone giving their own data to
anyone else with standard "do-not-reverse-engineer".

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [BK] upgrade will be needed

[David Weinehall]

On Mon, Feb 14, 2005 at 09:12:19AM -0800, Larry McVoy wrote:
> > >So how would you suggest that we resolve it?  The protection we need is
> > >that people don't get to
> > >
> > >   - use BK
> > >   - stop using BK so they can go work on another system
> > >   - start using BK again
> > >   - stop using BK so they can go work on another system
> > 
> > What??? Why not? BK is a PROGRAM. You can't tell somebody
> > that once they use some program in one job, they can't
> > use it again. What kind of "protection" are you claiming?
> 
> It is a program that comes with a license.  Licenses have terms which
> survive the termination of the license, that's industry standard, they
> all have such terms.
> 
> In this case the situation is unusual because we have a program that is
> ahead, in some ways, of all the other programs out there that do the
> same thing.  We'd like to protect that lead.  We put that lead at risk
> by giving you BK for free, that's more or less suicide because the open
> source world has a long track record of copying that which they find
> useful.  We don't want you to copy it.  If you can't agree to not copy
> it then you don't get to use it in the first place.

Does these license terms (the ones concerning developing competing
software while, or within a year of, using BK) also apply to the
commercial license?

BTW: Wishlist request.  Would you consider adding -p (--show-c-function)
to the set of flags used for the diffs created by BitKeeper?


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: [BK] upgrade will be needed

[Chris Wright]

* David Weinehall (tao@debian.org) wrote:
> BTW: Wishlist request.  Would you consider adding -p (--show-c-function)
> to the set of flags used for the diffs created by BitKeeper?

It's already there.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [BK] upgrade will be needed

[Marcin Dalecki]

On 2005-02-14, at 16:40, Larry McVoy wrote:
> So how would you suggest that we resolve it?  The protection we need is
> that people don't get to
>
>     - use BK
>     - stop using BK so they can go work on another system
>     - start using BK again
>     - stop using BK so they can go work on another system
>     ...

Give me a break!
Did may the idea perhaps occur to you that maybe the above wish list is:

1. Utterly immoral.
2. Something you are by no ways entitled to have.

If you want to be compensated for BK then put a price tag on it.
So what are you now trying to do is basically to use peoples wish to 
contribute to
free software as a measure to prohibiting them from competing with your 
commercial endeavor... that simply plain isn't fair play. 

Re: [BK] upgrade will be needed

[Russell Miller]

On Monday 14 February 2005 09:14, Marcin Dalecki wrote:

> Give me a break!
> Did may the idea perhaps occur to you that maybe the above wish list is:
>
> 1. Utterly immoral.
> 2. Something you are by no ways entitled to have.
>
> If you want to be compensated for BK then put a price tag on it.
> So what are you now trying to do is basically to use peoples wish to
> contribute to
> free software as a measure to prohibiting them from competing with your
> commercial endeavor... that simply plain isn't fair play.
>
It is certainly Larry's choice to license his software any way he chooses.

It is my choice whether or not to use it.

BK will never pollute my machine as long as simply using it will restrict me 
from any other development or programming activity.  I can understand it if 
the source code is made available.  If it's just a binary... this is going 
way too far.

--Russell

-- 

Russell Miller - rmiller@duskglow.com - Agoura, CA

Re: [BK] upgrade will be needed

[Larry McVoy]

On Monday 14 February 2005 09:14, Marcin Dalecki wrote:
> 1. Utterly immoral.
> 2. Something you are by no ways entitled to have.
>
> If you want to be compensated for BK then put a price tag on it.

Excellent idea.  At the volumes you are using it now that's $65M/year.
That's what we'd charge for the same number of seats at one commercial
site.  If it were spread out over the thousands of sites like your
usage is then it would be more, there's a lot more overhead.  There are
currently more than 2,200 top level domains using BK for free (where
top level means my-company.com, not my-workstation.my-company.com).

If someone wants to pay for it we'd be happy to negotiate a standard
click-wrap style license as part of the deal.  Everyone would like that
much better it seems.  Are you volunteering to pay?

On Mon, Feb 14, 2005 at 09:23:03AM -0800, Russell Miller wrote:
> It is certainly Larry's choice to license his software any way he chooses.
> 
> It is my choice whether or not to use it.

Yup, it is.  Always has been even for the kernel because of our hard
work to make sure of that.  We respect your choices, please respect ours.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[Marcin Dalecki]

On 2005-02-14, at 18:49, Larry McVoy wrote:
> r it we'd be happy to negotiate a standard
> click-wrap style license as part of the deal.  Everyone would like that
> much better it seems.  Are you volunteering to pay?

I'm not since I'm not using and I don't intend to use BK.
Oh BTW. the main reason for me is the incomprehendible user interface.

> On Mon, Feb 14, 2005 at 09:23:03AM -0800, Russell Miller wrote:
>> It is certainly Larry's choice to license his software any way he 
>> chooses.
>>
>> It is my choice whether or not to use it.
>
> Yup, it is.

No it isn't. What a license is, is very well defined by law and not by 
your
personal wish list.

Re: [BK] upgrade will be needed

[Steven Rostedt]

On Mon, 2005-02-14 at 09:49 -0800, Larry McVoy wrote:
> On Monday 14 February 2005 09:14, Marcin Dalecki wrote:

> On Mon, Feb 14, 2005 at 09:23:03AM -0800, Russell Miller wrote:
> > It is certainly Larry's choice to license his software any way he chooses.
> > 
> > It is my choice whether or not to use it.
> 
> Yup, it is.  Always has been even for the kernel because of our hard
> work to make sure of that.  We respect your choices, please respect ours.

I believe that Larry and Bitmover are fine with what they are doing.
They have every right to license their product the way they want as long
as they give it out for free (as in beer).  The problem that many people
here have is that Linus and company have chosen BK as their SCM for
Linux.  The effort of all those that disapprove of BK should not be
directed at Larry, but at Linus and others to convince them that the BK
license is not appropriate for Linux, and to find something else. If
this is a problem because everything else that is Free Software is not
capable for Linux then development should be done to what is out there
to make it adequate to the Linux Kernel development needs. Even if this
includes those that develop it not use BK. But this doesn't stop those
that do use it in telling those that develop something else what they
would like to have.  No license can stop you from listing what you would
like of a SCM.

-- Steve

Re: [BK] upgrade will be needed

[Steven Rostedt]

On Mon, 2005-02-14 at 16:35 -0800, Larry McVoy wrote:
> On Mon, Feb 14, 2005 at 07:14:11PM -0500, Steven Rostedt wrote:
> > On Mon, 2005-02-14 at 16:00 -0800, Larry McVoy wrote:
> > > How about this?
> > > 
> > > http://lkml.org/lkml/2003/12/14/47
> > 
> > I don't know about others, but it solves my issues.  I'm one of the many
> > that use BK not for the changes, but just for the snapshots. This seems
> > to do it.  Warning, you will still not please a lot of the complainers
> > on the list, but myself (and others) would be satisfied.
> 
> Well it would sure help if you said that in public.  Unless people ask
> for this we aren't going to go build it and support it on bkbits.net.
> It needs to solve problems for a pile of people or we can't afford to do
> it.
> 

I wasn't very active on the list back then, but post something like this
again and I'll second it publicly. You may have already done so, but I
might have missed it. I'll cc the LKML to make this public anyway.

> > As someone mentioned. Still do what you were going to do (keep BK free
> > for Open Source albeit the restriction). But have this for those of us
> > that can't go with the restriction, but still like the latest snapshots
> > of the kernel. In essence, two free versions, where one is "more free"
> > but also "crippled".
> 
> There are HUGE costs with maintaining multiple versions, I'd like to
> avoid that.  We've specced out what it would cost us to maintain 
> old/new versions that talked to each other and it's more or less twice
> as much engineering because you have to backport each new feature needed
> for compat, you have to figure out which bugs have to be backported,
> etc., etc.  It is very very expensive and takes up the resources of our
> most important people.

I don't know the architecture of the tool, but I've worked on some
pretty big projects, that could disable most of the tool with just a
simple config option. Heck, the Linux kernel does this.  But if the
design of the tool is such that you can't disable features without
destroying others (like removing IE from Windows),  then I guess this is
not an option. 

I guess you are dealing with three groups of people.

1) The ones paying you. The companies that spend money to get things
done.  -- Needs full version of BK.

2) The Open Source developers, Linus and others that like BK and will
work with it with whatever license you give it. -- Needs strong version
of BK. Probably no more than 100 users (or less).

3) The Open Source users, tweakers, hackers that are not the core
developers. -- Needs only to checkout the kernel. Probably over 1000
users.  I fall in this category.

This is why we have asked about three versions. Obviously, Linus and
friends are the most important part for the Linux community, so even if
it hurts 2000 other people that only want to download the lastest
snapshots from BK, it really doesn't matter.  Let us complain, but
unless Linus decides to go elsewhere, we are stuck.  So don't do the
crippled version if it hurts Linus.

-- Steve

Re: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 08:00:59PM -0500, Steven Rostedt wrote:
> I guess you are dealing with three groups of people.
> 
> 1) The ones paying you. The companies that spend money to get things
> done.  -- Needs full version of BK.

Agreed.

> 2) The Open Source developers, Linus and others that like BK and will
> work with it with whatever license you give it. -- Needs strong version
> of BK. Probably no more than 100 users (or less).

We could handle these guys by selling/donating commercial seats.
But while we started out with the goal of helping the Linux effort,
specifically Linus, other open source projects have gotten past
the license and found value in the product: mysql, xaraya, xen, etc.
Whatever we do we can't do anything which would disrupt their efforts,
that's not reasonable.

> 3) The Open Source users, tweakers, hackers that are not the core
> developers. -- Needs only to checkout the kernel. Probably over 1000
> users.  I fall in this category.

Would the tarball + patch server suffice for you?  We could make a
ChangeSet file which had bk changes -v output in it and that would 
give you a fairly useful set of version information.  For those who
don't know, bk changes -v is output in time sorted order of changesets
with the changeset comments then each file's comments like the output
below.  

This server wouldn't be much use for someone trying to track down the
source of a bug, you'd really need the BK2CVS tree for that or a BK
tree.  In some ways, the BK2CVS tree is far nicer because you can do
binary search on it, but as Roman/Pavel/et al have pointed out sometimes
the commits in the CVS tree are too coarse if the cset you want is a
merge of 20 changesets on a branch.  In that case you want the BK tree.

But for people trying to easily track the head the tarball server might
be just the ticket.  Erik (codepoet guy) would probably love it (right?).
If it would help people feel better about us and/or make their lives easier
we can set up that server for all the repos on bkbits.net.  I suspect
that it would help at least some people out there.

--lm

ChangeSet@1.2044, 2005-02-14 18:09:02+00:00, rmk@flint.arm.linux.org.uk
+3 -0
  [ARM] Fix sparse warnings for Integrator builds.
  
  Add some missing __iomem annotations for Integrator machines.
  
  Signed-off-by: Russell King <rmk@arm.linux.org.uk>

  arch/arm/mach-integrator/impd1.c@1.9, 2005-02-14 18:03:31+00:00, rmk@flint.arm .linux.org.uk +1 -1
    Add sparse __iomem annotations.

  arch/arm/mach-integrator/time.c@1.9, 2005-02-14 18:03:31+00:00, rmk@flint.arm.  linux.org.uk +4 -4
    Add sparse __iomem annotations.
    Use "dev" rather than "rtc_base" for the device id when requesting
    the RTC interrupt.

  drivers/input/serio/ambakmi.c@1.13, 2005-02-14 18:03:31+00:00, rmk@flint.arm.l inux.org.uk +1 -1
    Add sparse __iomem annotations.


> This is why we have asked about three versions. Obviously, Linus and
> friends are the most important part for the Linux community, so even if
> it hurts 2000 other people that only want to download the lastest
> snapshots from BK, it really doesn't matter.  Let us complain, but
> unless Linus decides to go elsewhere, we are stuck.  So don't do the
> crippled version if it hurts Linus.
> 
> -- Steve
> 

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[Steven Rostedt]

On Mon, 2005-02-14 at 19:01 -0800, Larry McVoy wrote:

> Would the tarball + patch server suffice for you?  We could make a
> ChangeSet file which had bk changes -v output in it and that would 
> give you a fairly useful set of version information.  For those who
> don't know, bk changes -v is output in time sorted order of changesets
> with the changeset comments then each file's comments like the output
> below.  
> 

This is perfect for me. The only time I've ever used BK was when someone
told me that I needed the lastest snapshot from the bk-tree.  What I do
with the kernel is to port it, write drivers or customize it for
customers. So I'm not in the development part of the kernel (although
I'll report bugs and fixes when I find them). I really believe that the
majority that download the kernel from BK are doing things like I am and
not part of the core development team. 

Currently, I'm working on a customization of Ingo's RT version, so
really at the moment I don't even need access to BK. But with my
previous job, I was downloading the bk version quite a lot. But just to
get the latest updates. So what you have suggested would have been all
that I needed.  As I've mentioned, earlier. I work from job to job and
my needs change with each one. I joined in this discussion because it
could have affected me quite a bit, since someday I might be hired to
work on a SCM tool, and I'm very careful about NDAs and the like.
 
-- Steve

PS - I'm packing up now to drive to Boston. See everyone at
LinuxWorld ;-)

Re: [BK] upgrade will be needed

[Alexandre Oliva]

On Feb 15, 2005, lm@bitmover.com (Larry McVoy) wrote:

> For those who don't know, bk changes -v is output in time sorted
> order of changesets with the changeset comments then each file's
> comments like the output below.

> as Roman/Pavel/et al have pointed out sometimes the commits in the
> CVS tree are too coarse if the cset you want is a merge of 20
> changesets on a branch.

How would the `bk changes -v ' output look like for such a merge of 20
changesets on a branch?  Would it list the 20 merged changesets?

Also, would the changeset ids (ChangeSet@1.2044) match the revision
IDs in the CVS tree?

If so, it looks like this would provide the very bit of information
that I feel to be missing from the publicly-available Linux
repository.

> But for people trying to easily track the head the tarball server might
> be just the ticket.

Any chance of having such tarballs offered from an rsync server,
compressed with gzip --rsyncable?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 09:49:32AM -0800, lm wrote:
> If it were spread out over the thousands of sites like your
> usage is then it would be more, there's a lot more overhead.  There are
> currently more than 2,200 top level domains using BK for free (where
> top level means my-company.com, not my-workstation.my-company.com).

http://www.bitkeeper.com/domains.html

is a listing of the domains which have used bk-3.2.3 in the last 4
months.  It's slightly less than the claimed 2,200 because we looked
only at the bk-3.2.3 usage.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[Erik Andersen]

On Mon Feb 14, 2005 at 11:29:20AM -0800, Larry McVoy wrote:
> On Mon, Feb 14, 2005 at 09:49:32AM -0800, lm wrote:
> > If it were spread out over the thousands of sites like your
> > usage is then it would be more, there's a lot more overhead.  There are
> > currently more than 2,200 top level domains using BK for free (where
> > top level means my-company.com, not my-workstation.my-company.com).
> 
> http://www.bitkeeper.com/domains.html
> 
> is a listing of the domains which have used bk-3.2.3 in the last 4
> months.  It's slightly less than the claimed 2,200 because we looked
> only at the bk-3.2.3 usage.

Noting that I am included in the list (codepoet.org) -- do keep
in mind that not all cases of having 'used bk' are equal.  I
suspect my situation is similar to many others in that I have
only used bk in order to obtain source code for projects for
which code is otherwise not readily available.  Thats all.
Nothing else.  Call that using bk if you want, but I only do so
since there is no currently viable alternative method...  Without
an alternative method, I am forced to use bk.

If there were a viable alternative method to obtain current
source code for projects now in bk (such as a nightly project
snapshots, a read only bk2cvs/bk2whatever gateway) I would gladly
remove bk immediately and use that other method instead.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: [BK] upgrade will be needed

[Matthew Jacob]

> So how would you suggest that we resolve it?  The protection we need is
> that people don't get to
> 
>    - use BK
>    - stop using BK so they can go work on another system
>    - start using BK again
>    - stop using BK so they can go work on another system
>    ...
> 

I guess I don't see the advantage that accrues to BitMover Inc from
this or what you're trying to do here. I'm not trying to add kerosene
to a flame fest here, but I'm definitely scratching my head on this
one.

Is your concern that you don't want to provide a free tool to people
who then turn around to compete with you? That is, you don't want BK
to enable people to do things to harm BK and its ongoing development?

I mean- you're certainly free to impose whatever license you want, and
others are free to be happy or unhappy with that. I'm just trying to
figure out what you're actually trying to accomplish here.

Re: [BK] upgrade will be needed

[Marcin Dalecki]

On 2005-02-14, at 19:17, Matthew Jacob wrote:
>
> I mean- you're certainly free to impose whatever license you want, and
> others are free to be happy or unhappy with that. I'm just trying to
> figure out what you're actually trying to accomplish here.

He is simply plain dishonest about his intentions. And since he is 
driving a
company it's not difficult to deduce what his intentions really are: 
Making money.
That's plain and simple what all companies are all about.
Now you can start to guess how he wants to accomplish this.

Re: [BK] upgrade will be needed

[Matthew Jacob]

Umm- can't say I agree. I've known Larry since, oh, 1988, and up to
about 18 months ago I lived about 3 blocks away from him and his
family.

Larry is pretty honest. He certainly isn't as evil as many on this
list make him out to be.

> 
> He is simply plain dishonest about his intentions. And since he is
> driving a
> company it's not difficult to deduce what his intentions really are:
> Making money.
> That's plain and simple what all companies are all about.
> Now you can start to guess how he wants to accomplish this.
> 
>

Re: [BK] upgrade will be needed

[Matthias Andree]

On Mon, 14 Feb 2005, Marcin Dalecki wrote:

> He is simply plain dishonest about his intentions. And since he is
> driving a company it's not difficult to deduce what his intentions
> really are: Making money.  That's plain and simple what all companies
> are all about.  Now you can start to guess how he wants to accomplish
> this.

Please stop this offensive posting style unless you have a hard, really
hard proof. Of course Larry and his company want to make money (you know
the term open secret?), and they'd better not disappoint those who've
trusted in BK/Free; but if he asked to veil his intentions or out of
honest interest in consultations can only be judged after we've seen the
3.2.4 BK/Free license.

-- 
Matthias Andree

Re: [BK] upgrade will be needed

[Scott Lockwood]

>
> On 2005-02-14, at 19:17, Matthew Jacob wrote:
> He is simply plain dishonest about his intentions. And since he is
> driving a
> company it's not difficult to deduce what his intentions really are:
> Making money.
> That's plain and simple what all companies are all about.
> Now you can start to guess how he wants to accomplish this.

Excuse me, does this tinfoil hat belong to you? You seem to have droped
it, getting off that short bus over there...

Re: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 10:17:35AM -0800, Matthew Jacob wrote:
> > So how would you suggest that we resolve it?  The protection we need is
> > that people don't get to
> > 
> >    - use BK
> >    - stop using BK so they can go work on another system
> >    - start using BK again
> >    - stop using BK so they can go work on another system
> >    ...
> > 
> 
> I guess I don't see the advantage that accrues to BitMover Inc from
> this or what you're trying to do here. I'm not trying to add kerosene
> to a flame fest here, but I'm definitely scratching my head on this
> one.
> 
> Is your concern that you don't want to provide a free tool to people
> who then turn around to compete with you? That is, you don't want BK
> to enable people to do things to harm BK and its ongoing development?

All we are trying to do is 

    1.  Provide the open source community with a useful tool.
    2.  Prevent that from turning into the open source community
        creating a clone of our tool.

The reason this is complicated is that we are giving it away for free to
lots and lots of open source people.  If we only sold it there wouldn't
be a problem, it would be 10 years before a copy appeared because far
fewer of the open source crowd would even know it existed.  Giving it
away is almost asking for it to be copied.  The license is a way to say
that the price of free use is agreement you won't use the tool to copy
the tool in any way.

I agree that this sucks, having a license that restricts your creativity
is very annoying.  On the other hand, you don't have to agree to it.
You only have to agree to it if you want the benefits of using the tool.
It's not much different than deciding whether you want to buy it, there
is a cost and a benefit and for some people the benefits outweigh the
costs and for some they don't.

If anyone can think of a better way for us to both let you use the tool
and protect our hard work, I'm listening.  The repeated outrage over the
restrictions isn't any more fun for me than it is for you.  Any answer,
however, has to take our issues into consideration as well as yours.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[Adrian Bunk]

Disclaimer:
I did never use BK and I do not plan to use it.

On Mon, Feb 14, 2005 at 10:56:24AM -0800, Larry McVoy wrote:
> 
> All we are trying to do is 
> 
>     1.  Provide the open source community with a useful tool.
>     2.  Prevent that from turning into the open source community
>         creating a clone of our tool.
>...
> I agree that this sucks, having a license that restricts your creativity
> is very annoying.  On the other hand, you don't have to agree to it.
> You only have to agree to it if you want the benefits of using the tool.
> It's not much different than deciding whether you want to buy it, there
> is a cost and a benefit and for some people the benefits outweigh the
> costs and for some they don't.
> 
> If anyone can think of a better way for us to both let you use the tool
> and protect our hard work, I'm listening.  The repeated outrage over the
> restrictions isn't any more fun for me than it is for you.  Any answer,
> however, has to take our issues into consideration as well as yours.

I don't know about copyright law in other countries (and the USA have 
both a pretty different legal system and a pretty different copyright 
law than Germany), but in Germany the clause you mentioned is simply 
void according to German copyright law.

German copyright law doesn't distinguish whether you get money for 
allowing the usage of the program or not.

The licence is still valid but the clause is void.

I can accept a void licence clause because this doesn't make it 
non-void. That's not uncommon. Perhaps 95% of all software licences 
contain clauses that are simply void.

In case you ask:
No, there is no case law in Germany - we have a different legal system.

If you like it or not - at least for people in Germany, I see no way how 
the law allows you to enforce what you are trying to do.

You can say it might be morally wrong to break this licence clause - but 
this doesn't make it illegal.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [BK] upgrade will be needed

[Paolo Ciarrocchi]

On Mon, 14 Feb 2005 21:36:51 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> Disclaimer:
> I did never use BK and I do not plan to use it.

Same here, but just because I'm not a developer ;-)
 
[...]
> I don't know about copyright law in other countries (and the USA have
> both a pretty different legal system and a pretty different copyright
> law than Germany), but in Germany the clause you mentioned is simply
> void according to German copyright law.
> 
> German copyright law doesn't distinguish whether you get money for
> allowing the usage of the program or not.
> 
> The licence is still valid but the clause is void.
> 
> I can accept a void licence clause because this doesn't make it
> non-void. That's not uncommon. Perhaps 95% of all software licences
> contain clauses that are simply void.
> 
> In case you ask:
> No, there is no case law in Germany - we have a different legal system.
> 
> If you like it or not - at least for people in Germany, I see no way how
> the law allows you to enforce what you are trying to do.
> 
> You can say it might be morally wrong to break this licence clause - but
> this doesn't make it illegal.

I think this is true not only in Germany, if I were Larry I would
check if the licence is valid in EU.



-- 
Paolo <paolo dot ciarrocchi at gmail dot com>
msn: paolo407@hotmail.com
hello: ciarrop

Re: [BK] upgrade will be needed

[Henrik Persson]

Paolo Ciarrocchi wrote:
> On Mon, 14 Feb 2005 21:36:51 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> 
>>Disclaimer:
>>I did never use BK and I do not plan to use it.
> 
> 
> Same here, but just because I'm not a developer ;-)
>  
> [...]
> 
>>I don't know about copyright law in other countries (and the USA have
>>both a pretty different legal system and a pretty different copyright
>>law than Germany), but in Germany the clause you mentioned is simply
>>void according to German copyright law.
>>
>>German copyright law doesn't distinguish whether you get money for
>>allowing the usage of the program or not.
>>
>>The licence is still valid but the clause is void.
>>
>>I can accept a void licence clause because this doesn't make it
>>non-void. That's not uncommon. Perhaps 95% of all software licences
>>contain clauses that are simply void.
>>
>>In case you ask:
>>No, there is no case law in Germany - we have a different legal system.
>>
>>If you like it or not - at least for people in Germany, I see no way how
>>the law allows you to enforce what you are trying to do.
>>
>>You can say it might be morally wrong to break this licence clause - but
>>this doesn't make it illegal.

If we bring moral into the game, alot of people would say that it's 
immoral of bitmover to have such a license.. I might agree. ;)

> I think this is true not only in Germany, if I were Larry I would
> check if the licence is valid in EU.

Well..read the archives. This has been discussed at least once before, 
with the same conclusions.

This is just noise noise noise. We've heard it all before. :)

-- 
Henrik Persson

Re: [BK] upgrade will be needed

[Tom Felker]

On Monday 14 February 2005 12:56 pm, Larry McVoy wrote:

> All we are trying to do is
>
>     1.  Provide the open source community with a useful tool.
>     2.  Prevent that from turning into the open source community
>         creating a clone of our tool.
>
> The reason this is complicated is that we are giving it away for free to
> lots and lots of open source people.  If we only sold it there wouldn't
> be a problem, it would be 10 years before a copy appeared because far
> fewer of the open source crowd would even know it existed.  Giving it
> away is almost asking for it to be copied.  The license is a way to say
> that the price of free use is agreement you won't use the tool to copy
> the tool in any way.
>
> I agree that this sucks, having a license that restricts your creativity
> is very annoying.  On the other hand, you don't have to agree to it.
> You only have to agree to it if you want the benefits of using the tool.
> It's not much different than deciding whether you want to buy it, there
> is a cost and a benefit and for some people the benefits outweigh the
> costs and for some they don't.
>
> If anyone can think of a better way for us to both let you use the tool
> and protect our hard work, I'm listening.  The repeated outrage over the
> restrictions isn't any more fun for me than it is for you.  Any answer,
> however, has to take our issues into consideration as well as yours.

I really think the fewer restrictions you put on BK's use, the less likely it 
will be copied.  When the open source community copies something, it's not out 
of a desire to screw somebody over.  It's because they had an itch, a 
software need that couldn't easily be fulfilled otherwise, a demand.

Apparently there is a demand for good SCM, and BK can satisfy this, and you've 
done the very admirable thing of letting the open source community use BK at 
no cost.  But by putting such a heavy restriction on its use, you create a 
large portion of the community who won't or can't use it, and who therefore 
need a "copy" of it, which is exactly what you are trying to prevent.

This segment wouldn't be slowed down much by the restrictions anyway.  As long 
as the BT users who ask for features aren't "working on" the project (however 
you define that), they're almost certainly safe.  And even if they are, if 
they can afford a day in court, they have a chance of winning.  (I'm NOT 
suggesting anybody do this, just saying it's possible.)

Better for you would be to just not create this segment in the first place, by 
making the license as unrestrictive as you can while still making money.  If 
you take the non-compete clause out and leave it at "open repository and 
logs," then BT would be good enough for most everybody, and you wouldn't have 
to worry about a copy until after we're all using the Hurd.

Just a thought,
-- 
Tom Felker, <tcfelker@mtco.com>
<http://vlevel.sourceforge.net> - Stop fiddling with the volume knob.

Code is speech!

Re: [BK] upgrade will be needed

[James Bruce]

I agree with this 100%, and this is exactly the same conclusion we came 
to in our research lab.

Tom Felker wrote:
> I really think the fewer restrictions you put on BK's use, the less likely it 
> will be copied.  When the open source community copies something, it's not out 
> of a desire to screw somebody over.  It's because they had an itch, a 
> software need that couldn't easily be fulfilled otherwise, a demand.
> 
> Apparently there is a demand for good SCM, and BK can satisfy this, and you've 
> done the very admirable thing of letting the open source community use BK at 
> no cost.  But by putting such a heavy restriction on its use, you create a 
> large portion of the community who won't or can't use it, and who therefore 
> need a "copy" of it, which is exactly what you are trying to prevent.
> ...
> Better for you would be to just not create this segment in the first place, by 
> making the license as unrestrictive as you can while still making money.  If 
> you take the non-compete clause out and leave it at "open repository and 
> logs," then BT would be good enough for most everybody, and you wouldn't have 
> to worry about a copy until after we're all using the Hurd.

One person (out of 20 or so), refused to use BK   because he 
occasionally worked on a binary tree-diff in his spare time.  He was, of 
course, properly following the BK-free license, but it meant the 
projects he worked on never got switched from CVS, while everything else 
went BK.  It also kept us looking for replacements to make everyone 
happy.  We consider every possible alternative, even though by most 
measures they are inferior (There isn't an SCM that I've heard of that 
someone in our lab hasn't tried using).  The peer pressure, if you will, 
also made the holdout *more* involved in SCM development, which is 
almost surely *not* a help for BitMover.  New projects are not being put 
in BK anymore, either.

Maybe this is an overly long and excessively detailed account, but my 
interpretation of it is the following:  Without the no-compete (1) We'd 
all be using BK happily, (2) The holdout would not be working on an SCM 
anymore, and (3) Other SCM projects would not get the user testing they 
now enjoy from us.  I cannot speak for anyone else, but this is the 
effect on our lab, and for us, the clause has hurt BitMover's stated 
intention, not helped it.

  - Jim Bruce

P.S. According to what is now legend, one of the things that drove RMS 
to the FSF philosophy was a person at CMU who wouldn't share printer 
driver source code with him.
(http://www.catb.org/~esr/writings/rms-bio.html)

Re: [BK] upgrade will be needed

[Jeff Sipek]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On Mon, Feb 14, 2005 at 03:30:47PM -0600, Tom Felker wrote:
> I really think the fewer restrictions you put on BK's use, the less likely it 
> will be copied.  When the open source community copies something, it's not out 
> of a desire to screw somebody over.  It's because they had an itch, a 
> software need that couldn't easily be fulfilled otherwise, a demand.
> 
> Apparently there is a demand for good SCM, and BK can satisfy this, and you've 
> done the very admirable thing of letting the open source community use BK at 
> no cost.  But by putting such a heavy restriction on its use, you create a 
> large portion of the community who won't or can't use it, and who therefore 
> need a "copy" of it, which is exactly what you are trying to prevent.

I fully agree.

Josef "Jeff" Sipek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [BK] upgrade will be needed

[Marcin Dalecki]

On 2005-02-14, at 19:56, Larry McVoy wrote:
>
> All we are trying to do is
>
>     1.  Provide the open source community with a useful tool.
>     2.  Prevent that from turning into the open source community
>         creating a clone of our tool.
>

Now that's pathetic!

You recognize that point 2. is precisely the reason Linux is all about
in first place? Remind you: Linux - a free UNIX/POSIX system
clone done by people who where previously working on UNIX in first place
and just wanted a free version of it. By definition it is just that...

And in this copy-cat community you intend to thrive as "Mother Theresa" 
of SCM?
You still wonder why you provoke disgruntling?

Re: [BK] upgrade will be needed

[Horst von Brand]

Marcin Dalecki <martin@dalecki.de> said:
> On 2005-02-14, at 19:56, Larry McVoy wrote:
> > All we are trying to do is
> >
> >     1.  Provide the open source community with a useful tool.
> >     2.  Prevent that from turning into the open source community
> >         creating a clone of our tool.

> Now that's pathetic!

> You recognize that point 2. is precisely the reason Linux is all about
> in first place? Remind you: Linux - a free UNIX/POSIX system
> clone done by people who where previously working on UNIX in first place
> and just wanted a free version of it. By definition it is just that...

Linus has never worked on Unix in any form, and most of the other kernel
hackers hasn't either. Ever. It goes so far that at least at IBM people
working on AIX aren't allowed to even look at Linux code, and viceversa.

Please don't spread SCOX type FUD.

> And in this copy-cat community

That sounds dangerously close to diffamation...

>                                you intend to thrive as "Mother Theresa"
> of SCM?  You still wonder why you provoke disgruntling?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

RE: [BK] upgrade will be needed

[Hua Zhong]

> Linus has never worked on Unix in any form, and most of the 
> other kernel hackers hasn't either. Ever.

Huh? I believe they have used Unix, as in the BitKeeper case. In neither
case they get access to the source code of the software they use, to make
the comparison equal.

Whether they used a *free* Unix (and thus whether they could have been asked
to not go write a clone) is another matter.

Hua

Re: [BK] upgrade will be needed

[kernel]

On Mon, 2005-02-14 at 13:56, Larry McVoy wrote:

> All we are trying to do is 
> 
>     1.  Provide the open source community with a useful tool.
>     2.  Prevent that from turning into the open source community
>         creating a clone of our tool.
> 

lol



> I agree that this sucks, having a license that restricts your creativity
> is very annoying.  On the other hand, you don't have to agree to it.


Just catching up on this thread.  I guess I'm ultimately surprised that
the developers here don't create a system *they* like with *their*
knowledge and skillsets.  

With all of the complaining about BK you'd think there'd be an equal
alternative.

For everyone not liking Larry nor BK, why don't you use that as
inspiration to develop together a better app with terms more agreeable? 
Surely that would put a bit of vinegar in his p*ss, wouldn't it?

-fd

Re: [BK] upgrade will be needed

[linux-os]

On Tue, 15 Feb 2005, kernel wrote:

> On Mon, 2005-02-14 at 13:56, Larry McVoy wrote:
>
>> All we are trying to do is
>>
>>     1.  Provide the open source community with a useful tool.
>>     2.  Prevent that from turning into the open source community
>>         creating a clone of our tool.
>>
>
> lol
>
>
>
>> I agree that this sucks, having a license that restricts your creativity
>> is very annoying.  On the other hand, you don't have to agree to it.
>
>
> Just catching up on this thread.  I guess I'm ultimately surprised that
> the developers here don't create a system *they* like with *their*
> knowledge and skillsets.
>
> With all of the complaining about BK you'd think there'd be an equal
> alternative.
>
> For everyone not liking Larry nor BK, why don't you use that as
> inspiration to develop together a better app with terms more agreeable?
> Surely that would put a bit of vinegar in his p*ss, wouldn't it?
>
> -fd

I have two questions for Larry.

(1) If I use BK for company source-code development (purchased
product, I didn't buy it, the company did and they require
me to use it for my work) and I go to work for another company
that also uses BK, your license says I can't use BK at the other
company, which means that I can't work there.

This is unlawful. How do you intend to enforce this?

(2) If I use BK and I decide that I don't want to do business with
you or the courts say that I have to return the software, will my
source-code still be usable with, perhaps CVS? In other words
do I need BK to retrieve my company's intellectual property?

Note that there is a little company (was a big company until
the lawsuit), that used VOBS (container files) to store source-
code. Seems that when the license expired, the users couldn't get
their source code out. There was a lawsuit. Company lost
(of course). Seems you can't hold somebody's intellectual
property for ransom, at least in the United States.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: [BK] upgrade will be needed

[Helge Hafting]

linux-os wrote:

> On Tue, 15 Feb 2005, kernel wrote:
>
>> On Mon, 2005-02-14 at 13:56, Larry McVoy wrote:
>>
>>> All we are trying to do is
>>>
>>>     1.  Provide the open source community with a useful tool.
>>>     2.  Prevent that from turning into the open source community
>>>         creating a clone of our tool.
>>>
>>
>> lol
>>
>>
>>
>>> I agree that this sucks, having a license that restricts your 
>>> creativity
>>> is very annoying.  On the other hand, you don't have to agree to it.
>>
>>
>>
>> Just catching up on this thread.  I guess I'm ultimately surprised that
>> the developers here don't create a system *they* like with *their*
>> knowledge and skillsets.
>>
>> With all of the complaining about BK you'd think there'd be an equal
>> alternative.
>>
>> For everyone not liking Larry nor BK, why don't you use that as
>> inspiration to develop together a better app with terms more agreeable?
>> Surely that would put a bit of vinegar in his p*ss, wouldn't it?
>>
>> -fd
>
>
> I have two questions for Larry.
>
> (1) If I use BK for company source-code development (purchased
> product, I didn't buy it, the company did and they require
> me to use it for my work) and I go to work for another company
> that also uses BK, your license says I can't use BK at the other
> company, which means that I can't work there.

You can dislike the BK licencing all you want, but isn't there some 
misunderstandings here?
I believe you can _use_ any SCM-system you want whenever you want. Using 
bitkeeper in
one place does not prevent you from using it in another company also.  
Neither does using
any other SCM.

The limit lies in that you can't both use the *free* version of 
bitkeeper while also
*developing* some other SCM.  Note that the non-free bitkeeper, the one 
you pay for,
is licenced differently.   So if you use the *free* bitkeeper and some 
employer
want you to work developing another SCM, then you have these options:

1. Quit the job because you cannot legally do it while using the free 
bitkeeper.
2. Quit using the free bitkeeper, by switching to another SCM for that 
project.
3. Quit using the free bitkeeper by purchasing a commercial licence for 
bitkeeper instead.

So, you can have bitkeeper for free with a limiting license, or you can 
pay for an
unencumbered bitkeeper.  Or you can keep your money and not use bitkeeper,

>
> This is unlawful. How do you intend to enforce this?
>
> (2) If I use BK and I decide that I don't want to do business with
> you or the courts say that I have to return the software, will my
> source-code still be usable with, perhaps CVS? In other words
> do I need BK to retrieve my company's intellectual property?

I don't really see the problem here - if they tell you to cease and desist
using bitkeeper, then extract all your source first, before scrapping 
bitkeeper.
Then install some other SCM and get the source tree into that.  It is some
work of course, but not a rewrite!

> Note that there is a little company (was a big company until
> the lawsuit), that used VOBS (container files) to store source-
> code. Seems that when the license expired, the users couldn't get
> their source code out. There was a lawsuit. Company lost
> (of course). Seems you can't hold somebody's intellectual
> property for ransom, at least in the United States.

That's good.  It should mean that nobody can prevent you from switching
away from bitkeeper in an orderly fashion then.

Helge Hafting

Re: [BK] upgrade will be needed

[Clemens Schwaighofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/15/2005 09:19 PM, kernel wrote:

> Just catching up on this thread.  I guess I'm ultimately surprised that
> the developers here don't create a system *they* like with *their*
> knowledge and skillsets.  
> 
> With all of the complaining about BK you'd think there'd be an equal
> alternative.

there is no need for that. There is already one. Subversion is a more
than mature VCS. Apache group is switching to it, gcc people are
strongly thinking about it, and those two are _huge_ projects with tons
of developers, patches, trunks, etc.

Perhaps its about time, that linux also switches.

- --
[ Clemens Schwaighofer                      -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group                           ]
[                6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp        http://www.tbwajapan.co.jp ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCExY2jBz/yQjBxz8RAlHAAJ9TqcN1ry1PYkZOqc5NF4JiVjbivwCgi79W
6W1JMuOsX5hGvKFI3vL+NGU=
=NM1T
-----END PGP SIGNATURE-----

Re: [BK] upgrade will be needed

[Catalin Marinas]

Clemens Schwaighofer <cs@tequila.co.jp> wrote:
> On 02/15/2005 09:19 PM, kernel wrote:
>> With all of the complaining about BK you'd think there'd be an equal
>> alternative.
>
> there is no need for that. There is already one. Subversion is a more
> than mature VCS. Apache group is switching to it, gcc people are
> strongly thinking about it, and those two are _huge_ projects with tons
> of developers, patches, trunks, etc.

Subversion and BK are quite different. The first one is snapshot
oriented and the latter is changeset oriented (I find this a more
powerful concept). Subversion is not distributed (you have some helper
scripts but I don't know how stable they are), which is somehow
mandatory for the way Linux is developed. Subversion also lacks any
smart merging capabilities (it doesn't even remember what was
merged).

GNU Arch is probably as close as you can get regarding features and
performance (I can't compare the two since I've never used BK).

Catalin

Re: [BK] upgrade will be needed

[Schwaighofer Clemens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Catalin Marinas wrote:
| Clemens Schwaighofer <cs@tequila.co.jp> wrote:
|
|>On 02/15/2005 09:19 PM, kernel wrote:
|>
|>>With all of the complaining about BK you'd think there'd be an equal
|>>alternative.
|>
|>there is no need for that. There is already one. Subversion is a more
|>than mature VCS. Apache group is switching to it, gcc people are
|>strongly thinking about it, and those two are _huge_ projects with tons
|>of developers, patches, trunks, etc.
|
|
| Subversion and BK are quite different. The first one is snapshot
| oriented and the latter is changeset oriented (I find this a more
| powerful concept). Subversion is not distributed (you have some helper
| scripts but I don't know how stable they are), which is somehow
| mandatory for the way Linux is developed. Subversion also lacks any
| smart merging capabilities (it doesn't even remember what was
| merged).
|
| GNU Arch is probably as close as you can get regarding features and
| performance (I can't compare the two since I've never used BK).

well yes, I never searched for a distributed VCS, thats why I never
tried GNU Arch not so much (but I have to say, that it has hyper complex
command line options, perhaps darcs might be better).

Furthermore I sadly have to admit that I don't know the exact difference
between snapshot and changeset oriented. I just know that subversion has
~ Atomic comits and it works more than fine for me :)

Perhaps somebody can point me out to some Documentation about that (can
be in PM and not to the list)

lg, Clemens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCE01KjBz/yQjBxz8RAgumAKDPg8I0hJU+rs/UIb0wRcgQy2dPOwCcDy6g
4994vMzy66WeTuB/fArYgMY=
=Nyim
-----END PGP SIGNATURE-----

Re: [BK] upgrade will be needed

[d.c]

El Wed, 16 Feb 2005 18:45:27 +0900,
Clemens Schwaighofer <cs@tequila.co.jp> escribió:

> than mature VCS. Apache group is switching to it, gcc people are
> strongly thinking about it, and those two are _huge_ projects with tons
> of developers, patches, trunks, etc.

....and all of them work today with CVS, so any SCM will fit their purposes.



> Perhaps its about time, that linux also switches.

Linux kernel is patch + diff + announcement based (there's no need to use BK)
I really would like it was different but...

Re: [BK] upgrade will be needed

[Clemens Schwaighofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/17/2005 12:39 AM, d.c wrote:
> El Wed, 16 Feb 2005 18:45:27 +0900,
> Clemens Schwaighofer <cs@tequila.co.jp> escribió:
> 
> 
>>than mature VCS. Apache group is switching to it, gcc people are
>>strongly thinking about it, and those two are _huge_ projects with tons
>>of developers, patches, trunks, etc.
> 
> 
> ....and all of them work today with CVS, so any SCM will fit their purposes.

so, your point it is, because linux used none before, none than bk fit?

- --
[ Clemens Schwaighofer                      -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group                           ]
[                6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp        http://www.tbwajapan.co.jp ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCE+HpjBz/yQjBxz8RAr8lAJ4w6TK0c7H1fjs178Y9Q0Mr4hdGBgCg32cT
LUSf7DWy++w+cczaHpeEnIs=
=zRM5
-----END PGP SIGNATURE-----

Re: [BK] upgrade will be needed

[Olivier Galibert]

On Wed, Feb 16, 2005 at 06:45:27PM +0900, Clemens Schwaighofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02/15/2005 09:19 PM, kernel wrote:
> 
> > Just catching up on this thread.  I guess I'm ultimately surprised that
> > the developers here don't create a system *they* like with *their*
> > knowledge and skillsets.  
> > 
> > With all of the complaining about BK you'd think there'd be an equal
> > alternative.
> 
> there is no need for that. There is already one. Subversion is a more
> than mature VCS. Apache group is switching to it, gcc people are
> strongly thinking about it, and those two are _huge_ projects with tons
> of developers, patches, trunks, etc.
> 
> Perhaps its about time, that linux also switches.

Think what you want of Larry, but SVN is nowhere near BK is term of
capabilities (and neither is arch for he matter).  It's only better
compared to cvs, and then not by that much.

SCM is hard and not sexy, I'm afraid.

  OG.

Re: [BK] upgrade will be needed

[Sean]

On Wed, February 16, 2005 10:43 am, Olivier Galibert said:
> Think what you want of Larry, but SVN is nowhere near BK is term of
> capabilities (and neither is arch for he matter).  It's only better
> compared to cvs, and then not by that much.
>
> SCM is hard and not sexy, I'm afraid.

This has nothing to do with Larry personally.   The point is that some
people keep saying BK is better without stopping to think if the supposed
advantages are honestly needed.   They come with a rather large cost of
reducing some people to second class participants and reducing the freedom
to use collected metadata.   Since svn or arch could fill the role quite
nicely without these problems, it makes you wonder if the price of BK is
too high for whatever advantage it provides over these other choices.  
Unfortunately the decision has already been made, so this is all academic.

Sean

Re: [BK] upgrade will be needed

[Clemens Schwaighofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/17/2005 12:43 AM, Olivier Galibert wrote:

>>Perhaps its about time, that linux also switches.
> 
> 
> Think what you want of Larry, but SVN is nowhere near BK is term of
> capabilities (and neither is arch for he matter).  It's only better
> compared to cvs, and then not by that much.

first. what kind of advantages does bk have over other svn? Seriously.
If Apache can use it, and gcc might use it (again two very large
projects), what makes linux so differetnt that it can't.

And I don't want _anything_ from Larry. I am just pointing out, that
this kind of legal clause is more ridicolous than understandable.

Last, why can you compare cvs to bk? and not subversion, or arch? arch
and subversion are way superiour to cvs ...

> SCM is hard and not sexy, I'm afraid.

yes its hard, so we have to use bk with a very strange license?
better close the eyes and not change. What do you think is kernel
coding? Walk in the park? Do you think all those developers say, nah I
better use Windows or Mac OS X, because its hard and not sexy ... pah
... BS!

- --
[ Clemens Schwaighofer                      -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group                           ]
[                6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp        http://www.tbwajapan.co.jp ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCE+FAjBz/yQjBxz8RAjgHAKDf03ccZzlYDaFcZtNyG5Do3pba0QCfQk31
R7mSvvgMI7IQ9C4/ahc0Hak=
=L8t2
-----END PGP SIGNATURE-----

Re: [BK] upgrade will be needed

[Theodore Ts'o]

On Thu, Feb 17, 2005 at 09:11:45AM +0900, Clemens Schwaighofer wrote:
> 
> first. what kind of advantages does bk have over other svn? Seriously.
> If Apache can use it, and gcc might use it (again two very large
> projects), what makes linux so differetnt that it can't.

Compare the number of developers, the number of overlapping
simultaneous development trees, and the number of patches that touch
overlapping files, and you'll begin to start to appreciate the
difference between a system that can work for Linux, and a system that
can working for simpler projects.

						- Ted

Re: [BK] upgrade will be needed

[Sean]

On Wed, February 16, 2005 11:57 pm, Theodore Ts'o said:
> On Thu, Feb 17, 2005 at 09:11:45AM +0900, Clemens Schwaighofer wrote:
>>
>> first. what kind of advantages does bk have over other svn? Seriously.
>> If Apache can use it, and gcc might use it (again two very large
>> projects), what makes linux so differetnt that it can't.
>
> Compare the number of developers, the number of overlapping
> simultaneous development trees, and the number of patches that touch
> overlapping files, and you'll begin to start to appreciate the
> difference between a system that can work for Linux, and a system that
> can working for simpler projects.
>

Hey Ted,

Considering that the kernel was being developed without BK for a long time
it's rather obvious that _any_ version control system could have improved
the situation.   BK gets credit for improving the situation, but much of
that improvment could have been achieved with any of the simpler and truly
free options too.

Even today, some top developers do not use BK and manage to get along
fine.  BK offers some advantages over simpler version control offerings
but the price is too high.  It's disappointing to see so many top
developers not give a damn about its costs and ignore the difficulties it
creates for many.

Cheers,
Sean

Re: [BK] upgrade will be needed

[d.c]

El Thu, 17 Feb 2005 00:57:55 -0500 (EST),
"Sean" <seanlkml@sympatico.ca> escribió:

> Even today, some top developers do not use BK and manage to get along


Do like them, ignore BK and continue using patch & diff. BK is just a option, It 
doesn't stops you from developing in the linux kernel, I can't understand why
people cares so much about BK.

Re: [BK] upgrade will be needed

[Sean]

On Thu, February 17, 2005 1:22 am, d.c said:

> Do like them, ignore BK and continue using patch & diff. BK is just a
> option, It doesn't stops you from developing in the linux kernel, I
> can't understand  why people cares so much about BK.

The affects of many top level folks using a non free system is felt all
the way down the food-chain.  If the top tier would agree to use a free
SCM system then we could build bridges and offer the data in the preferred
format to _everyone_  (arch, subversion, patch, BK, etc).  But because BK
is used at the top, many useful options are cut off.   It's a rather large
"hidden" cost of BK adoption as the primary tool at the top.

Cheers,
Sean

Re: [BK] upgrade will be needed

[Lee Revell]

On Thu, 2005-02-17 at 01:49 -0500, Sean wrote:
> The affects of many top level folks using a non free system is felt all
> the way down the food-chain.  If the top tier would agree to use a free
> SCM system then we could build bridges and offer the data in the preferred
> format to _everyone_  (arch, subversion, patch, BK, etc).  But because BK
> is used at the top, many useful options are cut off.   It's a rather large
> "hidden" cost of BK adoption as the primary tool at the top.

If you don't like it you are free to write a better SCM that is free
software.  I am sure if you brought Linus a free software SCM that's as
good as BK he would use it.  Bitching about it on LKML will not get you
any closer to having said SCM.

Lee

Re: [BK] upgrade will be needed

[Sean]

On Thu, February 17, 2005 11:34 am, Lee Revell said:

> If you don't like it you are free to write a better SCM that is free
> software.  I am sure if you brought Linus a free software SCM that's as
> good as BK he would use it.  Bitching about it on LKML will not get you
> any closer to having said SCM.

Lee,

Your cookie cutter response, proves you didn't really absorb the content
of my message.   Please reread; there was no "bitching" at all.

Cheers,
Sean

Re: [BK] upgrade will be needed

[Chris Friesen]

Sean wrote:

> Your cookie cutter response, proves you didn't really absorb the content
> of my message.   Please reread; there was no "bitching" at all.

If you look at the archives, there have been a *lot* of people saying 
very much the same thing as you.  I suspect people are getting tired of 
giving the same responses all the time.

Here is what Linus had to say about it a while back:

    If people in the open-source SCM community wake up and notice that
    the current open-source SCM systems aren't cutting it, that's _good_.
    But it's absolutely NOT an excuse to use them today.  Sorry.  I use
    CVS at work, and I could never use it for Linux.  I took a look at
    subversion, and it doesn't even come close to what I wanted.

    And I personally refuse to use inferior tools because of ideology. In
    fact, I will go as far as saying that making excuses for bad tools
    due to ideology is _stupid_, and people who do that think with their
    gonads, not their brains.

Chris

Re: [BK] upgrade will be needed

[Sean]

On Thu, February 17, 2005 11:55 am, Chris Friesen said:

> If you look at the archives, there have been a *lot* of people saying
> very much the same thing as you.  I suspect people are getting tired of
> giving the same responses all the time.
>
> Here is what Linus had to say about it a while back:
>
>     If people in the open-source SCM community wake up and notice that
>     the current open-source SCM systems aren't cutting it, that's _good_.
>     But it's absolutely NOT an excuse to use them today.  Sorry.  I use
>     CVS at work, and I could never use it for Linux.  I took a look at
>     subversion, and it doesn't even come close to what I wanted.
>
>     And I personally refuse to use inferior tools because of ideology. In
>     fact, I will go as far as saying that making excuses for bad tools
>     due to ideology is _stupid_, and people who do that think with their
>     gonads, not their brains.

Chris,

Yes, I do remember that post.  But i'm not arguing from an ideological
basis; i'm arguing on practical grounds that the price of using BK is too
high for its supposed benefits.  I've not seen anyone else make that
argument here on the list and it is something that Linus may not have
given full consideration to.   At least the comment that you quote gives
no consideration to it at all.

Cheers,
Sean

Re: [BK] upgrade will be needed

[Horst von Brand]

"Sean" <seanlkml@sympatico.ca> said:
> On Thu, February 17, 2005 11:55 am, Chris Friesen said:
> > If you look at the archives, there have been a *lot* of people saying
> > very much the same thing as you.  I suspect people are getting tired of
> > giving the same responses all the time.
> >
> > Here is what Linus had to say about it a while back:
> >
> >     If people in the open-source SCM community wake up and notice that
> >     the current open-source SCM systems aren't cutting it, that's _good_.
> >     But it's absolutely NOT an excuse to use them today.  Sorry.  I use
> >     CVS at work, and I could never use it for Linux.  I took a look at
> >     subversion, and it doesn't even come close to what I wanted.
> >
> >     And I personally refuse to use inferior tools because of ideology. In
> >     fact, I will go as far as saying that making excuses for bad tools
> >     due to ideology is _stupid_, and people who do that think with their
> >     gonads, not their brains.

> Yes, I do remember that post.  But i'm not arguing from an ideological
> basis; i'm arguing on practical grounds that the price of using BK is too
> high for its supposed benefits.

"Best tool for the job" certainly includes minutiae like "benefits" and
"price". 

>                                  I've not seen anyone else make that
> argument here on the list and it is something that Linus may not have
> given full consideration to.   At least the comment that you quote gives
> no consideration to it at all.

It doesn't do so overtly, no. Doesn't mean it wasn't part of the equation.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [BK] upgrade will be needed

[Sean]

On Thu, February 17, 2005 3:52 pm, Horst von Brand said:

> "Best tool for the job" certainly includes minutiae like "benefits" and
> "price".

Thank you, that's my point.  It's not just about the geeky microscopic
technical details.

Sean

Re: [BK] upgrade will be needed

[Horst von Brand]

"Sean" <seanlkml@sympatico.ca> said:
> On Thu, February 17, 2005 3:52 pm, Horst von Brand said:

[...]

> > "Best tool for the job" certainly includes minutiae like "benefits" and
> > "price".

> Thank you, that's my point.  It's not just about the geeky microscopic
> technical details.

Linus clearly considered not just his /own/ workflow, but the workflow for
the /whole/ kernel development community. In fact, BK was designed around
the requirements Linus and other head hackers laid down for a SCM for use
in Linux. And I'm quite sure that if Linus et al had serious misgivings
about the license somehow hindering Linux development, they would have got
it fixed or dumped BK. Linus has said time and again that he just cares for
the very best kernel possible, nothing else.

Sure, from the periphery of kernel development using something else looks
simple. But you have to consider there are literaly dozens of trees (of the
head maintainers) exchanging changesets. The flow of going into 2.6 is
astonishing right now, I'd say some 3 or 5 times more than what got into
the most furious 2.3 patch frenzies. Existing open source tools just aren't
up to the task, as Linus has repeatedly said. Just now there are starting
to be halfways useful SCM systems (almost all based on the "one central
repository" idea, which doesn't cut it for Linux), but they aren't proven
enough.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [BK] upgrade will be needed

[Sean]

On Thu, February 17, 2005 8:42 pm, Horst von Brand said:

> Linus clearly considered not just his /own/ workflow, but the workflow
> for the /whole/ kernel development community. In fact, BK was designed

Well, the /whole/ community isn't yet included, that's what we're talking
about.

> around the requirements Linus and other head hackers laid down for a
> SCM for use in Linux. And I'm quite sure that if Linus et al had
> serious misgivings about the license somehow hindering Linux
> development, they would have got it fixed or dumped BK. Linus has
> said time and again that he  just cares for the very best kernel
> possible, nothing else.

Do you think that the developers who must or want to use other SCM tools
desire less?

> Sure, from the periphery of kernel development using something else looks
> simple. But you have to consider there are literaly dozens of trees (of
> the head maintainers) exchanging changesets. The flow of going into
> 2.6 is astonishing right now, I'd say some 3 or 5 times more than
> what got into the most furious 2.3 patch frenzies. Existing open
> source tools just aren't up to the task, as Linus has repeatedly said.

There are ways that the tools could coexist and work together better than
they do today. If people would stop acting like BK was in jeopardy of
being taken away from them and realize that others just want the ability
to use their tools of choice too.

> Just now there are starting to be halfways useful SCM systems (almost
> all based on the "one central repository" idea, which doesn't cut it
> for Linux), but they aren't proven enough.

Yeah, there are some glimmers of hope for sure, but you're right they're a
ways off.

Sean

Re: [BK] upgrade will be needed

[Theodore Ts'o]

On Fri, Feb 18, 2005 at 02:52:20AM -0500, Sean wrote:
> There are ways that the tools could coexist and work together better than
> they do today. If people would stop acting like BK was in jeopardy of
> being taken away from them and realize that others just want the ability
> to use their tools of choice too.

If you truly believe that BK would be able to add the value that it
does to the kernel development process by using some other SCM as the
master SCM, with BK being "underneath", as you proposed earlier, then
you do not understand why BK is fundamentally better than the current
open source SCM systems that are out there.

And people *can* use the tools of their choice today.  They can use
CVS, and diff+patch, and suffer with all of the limitations that those
tools have today.  And for people who are doing stuff around the
periphery, quilt is often really the best tool for them.  

> > Linus clearly considered not just his /own/ workflow, but the workflow
> > for the /whole/ kernel development community. In fact, BK was designed
> 
> Well, the /whole/ community isn't yet included, that's what we're talking
> about.

If it's about the whole ***kernel*** development community, then it's
pretty clear that the current system works quite well.  All of the
complaints have been coming primarily from SCM hackers, it seems, and
not people who truly need the power of more powerful than downloading
the bk snapshots, using the CVS export tree, and in the case where
they need to look at the changes in a single changeset bkbits.net.  

The "cost" of using BK seems to be primarily more theoretical, and
ideological, than real.  It's always seems to be about someone
kvetching that they want to use SVN and get finely grained changsets
through SVN, and they can't.  But how often does that happen, and
what's so painful of getting the finely grained changeset through
bkbits.net?  Not very.  So at the end of the day, it finally boils
down to being all about ideology, doesn't it?

Once again proving that Linus, as is often the case, was right all
along.

						- Ted

Re: [BK] upgrade will be needed

[Sean]

On Fri, February 18, 2005 11:27 am, Theodore Ts'o said:

> If you truly believe that BK would be able to add the value that it
> does to the kernel development process by using some other SCM as the
> master SCM, with BK being "underneath", as you proposed earlier, then
> you do not understand why BK is fundamentally better than the current
> open source SCM systems that are out there.

BK already feeds patches out at the head, surely if it's as powerful as
you think, it could feed a free SCM too for your non-bk friends in the
community.

> And people *can* use the tools of their choice today.  They can use
> CVS, and diff+patch, and suffer with all of the limitations that those
> tools have today.  And for people who are doing stuff around the
> periphery, quilt is often really the best tool for them.

The situation could be improved for these other tools if there wasn't so
much BK zealotry from those that use it.

> If it's about the whole ***kernel*** development community, then it's
> pretty clear that the current system works quite well.  All of the
> complaints have been coming primarily from SCM hackers, it seems, and
> not people who truly need the power of more powerful than downloading
> the bk snapshots, using the CVS export tree, and in the case where
> they need to look at the changes in a single changeset bkbits.net.

There's no technical reason for this limitation.

> The "cost" of using BK seems to be primarily more theoretical, and
> ideological, than real.  It's always seems to be about someone
> kvetching that they want to use SVN and get finely grained changsets
> through SVN, and they can't.  But how often does that happen, and
> what's so painful of getting the finely grained changeset through
> bkbits.net?  Not very.  So at the end of the day, it finally boils
> down to being all about ideology, doesn't it?

No.  It's just that the cost isn't being paid by you, so you don't care.


Cheers,
Sean.

Re: [BK] upgrade will be needed

[Dmitry Torokhov]

On Fri, 18 Feb 2005 13:34:23 -0500 (EST), Sean <seanlkml@sympatico.ca> wrote:
> On Fri, February 18, 2005 11:27 am, Theodore Ts'o said:
> 
> > If you truly believe that BK would be able to add the value that it
> > does to the kernel development process by using some other SCM as the
> > master SCM, with BK being "underneath", as you proposed earlier, then
> > you do not understand why BK is fundamentally better than the current
> > open source SCM systems that are out there.
> 
> BK already feeds patches out at the head, surely if it's as powerful as
> you think, it could feed a free SCM too for your non-bk friends in the
> community.

What is bk2cvs gateway that is maintained by Larry then? Just call it
your "head" that Linus feeds from his BK repository and you are all
set.

I can see  that Roman and Stellian want something different, but we
alerady have what you have just described.

-- 
Dmitry

Re: [BK] upgrade will be needed

[Sean]

On Fri, February 18, 2005 2:26 pm, Dmitry Torokhov said:

> What is bk2cvs gateway that is maintained by Larry then? Just call it
> your "head" that Linus feeds from his BK repository and you are all
> set.
>
> I can see  that Roman and Stellian want something different, but we
> alerady have what you have just described.
>

Bitkeeper isn't motivated to raise the bar in terms of implementation, nor
is cvs the best choice in terms of which free tool to use.   Once a free
SCM is actually used at the head, there are opportunities to implement
updating too, not just pulling.

Cheers,
Sean

Re: [BK] upgrade will be needed

[John Stoffel]

>>>>> "Sean" == Sean  <seanlkml@sympatico.ca> writes:

Sean> Bitkeeper isn't motivated to raise the bar in terms of
Sean> implementation, nor is cvs the best choice in terms of which
Sean> free tool to use.  Once a free SCM is actually used at the head,
Sean> there are opportunities to implement updating too, not just
Sean> pulling.

Great, come on back when you've implemented this new tool and show
everyone how great it is.

John

Re: [BK] upgrade will be needed

[Dmitry Torokhov]

On Fri, 18 Feb 2005 14:31:20 -0500 (EST), Sean <seanlkml@sympatico.ca> wrote:
> On Fri, February 18, 2005 2:26 pm, Dmitry Torokhov said:
> 
> > What is bk2cvs gateway that is maintained by Larry then? Just call it
> > your "head" that Linus feeds from his BK repository and you are all
> > set.
> >
> > I can see  that Roman and Stellian want something different, but we
> > alerady have what you have just described.
> >
> 
> Bitkeeper isn't motivated to raise the bar in terms of implementation, nor
> is cvs the best choice in terms of which free tool to use.

You from cvs you can import into other SCM of your choise.

>  Once a free
> SCM is actually used at the head, there are opportunities to implement
> updating too, not just pulling.

Heh, you don't get to update the master repository even if you are
using BK.  And you are free to update your local tree with
CVS/SVN/whatever. So I am not sure why you trying this argument.

-- 
Dmitry

Re: [BK] upgrade will be needed

[Sean]

On Fri, February 18, 2005 2:49 pm, Dmitry Torokhov said:

> You from cvs you can import into other SCM of your choise.

This isn't true unfortunately, a lot of information is lost in cvs.  file
deletes, renames etc..   Plus, the implementation from Bitkeeper is
lacking, (eg. combining many changes into one).

>
> Heh, you don't get to update the master repository even if you are
> using BK.  And you are free to update your local tree with
> CVS/SVN/whatever. So I am not sure why you trying this argument.

Yeah,  I didn't mean to suggest that it be opened up to the public :o) 
Just that the flow of information wouldn't all have to originate in bk to
make it into head (ie. bk could pull changes from head too).

Cheers,
Sean.

Re: [BK] upgrade will be needed

[Horst von Brand]

"Sean" <seanlkml@sympatico.ca> said:

[...]

> Yeah,  I didn't mean to suggest that it be opened up to the public :o) 
> Just that the flow of information wouldn't all have to originate in bk to
> make it into head (ie. bk could pull changes from head too).

No problem. bk can happily import patches, which you can certainly get out
of any other SCM.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [BK] upgrade will be needed

[d.c]

El Fri, 18 Feb 2005 13:34:23 -0500 (EST),
"Sean" <seanlkml@sympatico.ca> escribió:


> BK already feeds patches out at the head, surely if it's as powerful as
> you think, it could feed a free SCM too for your non-bk friends in the
> community.

Who cares, really?

1) Linux was never supposed to have a "head", but -pre/-rc diff patches

2) And more important, *nobody* works against "linus' bk head". Everyone who
    is implementing something so intrusive that needs to keep track of the
    "development head" developes again the _true_ "head" of the linux
    kernel - akpm's tree.


In fact is surprising that so many people are bitching about BK and nobody
has complained that the -mm tree is not available through a SCM system (be it free
or not), which should be a issue _much_ bigger than any problem you've with
BK. I just don't get it, in my opinion people who whines about BK is people
who just don't like BK and can't accept the fact that BK is really helping
to linux development. When RMS started GNU he had to use non-free tools
and systems to work on it because everythin else sucked or it would have been
more difficult, I don't think BK is much different in this regard.

Re: [BK] upgrade will be needed

[David S. Miller]

On Fri, 18 Feb 2005 21:45:55 +0100
"d.c" <aradorlinux@yahoo.es> wrote:

> 2) And more important, *nobody* works against "linus' bk head".

I do, %100 exclusively, for all the networking and sparc
development.

I never work against the -mm tree.

Re: [BK] upgrade will be needed

[Anton Altaparmakov]

On Fri, 18 Feb 2005, David S. Miller wrote:
> On Fri, 18 Feb 2005 21:45:55 +0100
> "d.c" <aradorlinux@yahoo.es> wrote:
> 
> > 2) And more important, *nobody* works against "linus' bk head".
> 
> I do, %100 exclusively, for all the networking and sparc
> development.
> 
> I never work against the -mm tree.

Dito.  All my kernel development happens against Linus' bk head and I 
almost never work against -mm tree.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [BK] upgrade will be needed

[Vojtech Pavlik]

On Fri, Feb 18, 2005 at 09:34:47PM +0000, Anton Altaparmakov wrote:
> On Fri, 18 Feb 2005, David S. Miller wrote:
> > On Fri, 18 Feb 2005 21:45:55 +0100
> > "d.c" <aradorlinux@yahoo.es> wrote:
> > 
> > > 2) And more important, *nobody* works against "linus' bk head".
> > 
> > I do, %100 exclusively, for all the networking and sparc
> > development.
> > 
> > I never work against the -mm tree.
> 
> Dito.  All my kernel development happens against Linus' bk head and I 
> almost never work against -mm tree.

Same here, I work on Linus's bk head and all the changes go to -mm for
testing first, then to Linus for inclusion.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [BK] upgrade will be needed

[Dmitry Torokhov]

On Fri, 18 Feb 2005 23:18:19 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> On Fri, Feb 18, 2005 at 09:34:47PM +0000, Anton Altaparmakov wrote:
> > On Fri, 18 Feb 2005, David S. Miller wrote:
> > > On Fri, 18 Feb 2005 21:45:55 +0100
> > > "d.c" <aradorlinux@yahoo.es> wrote:
> > >
> > > > 2) And more important, *nobody* works against "linus' bk head".
> > >
> > > I do, %100 exclusively, for all the networking and sparc
> > > development.
> > >
> > > I never work against the -mm tree.
> >
> > Dito.  All my kernel development happens against Linus' bk head and I
> > almost never work against -mm tree.
> 
> Same here, I work on Linus's bk head and all the changes go to -mm for
> testing first, then to Linus for inclusion.
> 

I guess there is a perception that developers/maintainers are working
against -mm because all maintainers trees are automatically pulled by
Andrew. And when someone doing stuff on somewhat regular basis he/she
tends to do it against maintainer's tree thus making patches suitable
for -mm as well.
 
-- 
Dmitry

Re: [BK] upgrade will be needed

[Anton Altaparmakov]

On Fri, 18 Feb 2005, Dmitry Torokhov wrote:
> On Fri, 18 Feb 2005 23:18:19 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> > On Fri, Feb 18, 2005 at 09:34:47PM +0000, Anton Altaparmakov wrote:
> > > On Fri, 18 Feb 2005, David S. Miller wrote:
> > > > On Fri, 18 Feb 2005 21:45:55 +0100
> > > > "d.c" <aradorlinux@yahoo.es> wrote:
> > > >
> > > > > 2) And more important, *nobody* works against "linus' bk head".
> > > >
> > > > I do, %100 exclusively, for all the networking and sparc
> > > > development.
> > > >
> > > > I never work against the -mm tree.
> > >
> > > Dito.  All my kernel development happens against Linus' bk head and I
> > > almost never work against -mm tree.
> > 
> > Same here, I work on Linus's bk head and all the changes go to -mm for
> > testing first, then to Linus for inclusion.
> 
> I guess there is a perception that developers/maintainers are working
> against -mm because all maintainers trees are automatically pulled by
> Andrew. And when someone doing stuff on somewhat regular basis he/she
> tends to do it against maintainer's tree thus making patches suitable
> for -mm as well.

Ah yes, that is possible.  However at least for me I work against Linus' 
BK head, but my developmental NTFS tree is pulled by Andrew for -mm.  When 
I consider a release ready I request inclusion into Linus' tree.  For 
non-ntfs stuff I generally send to Andrew for -mm (like the loop driver 
fallback to file write patch I sent him a few days ago) and he can merge 
it into mainline later.

I imagine it is simillar for most maintainers trees.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [BK] upgrade will be needed

[Bill Davidsen]

d.c wrote:
> El Fri, 18 Feb 2005 13:34:23 -0500 (EST),
> "Sean" <seanlkml@sympatico.ca> escribió:
> 
> 
> 
>>BK already feeds patches out at the head, surely if it's as powerful as
>>you think, it could feed a free SCM too for your non-bk friends in the
>>community.
> 
> 
> Who cares, really?
> 
> 1) Linux was never supposed to have a "head", but -pre/-rc diff patches
> 
> 2) And more important, *nobody* works against "linus' bk head". Everyone who
>     is implementing something so intrusive that needs to keep track of the
>     "development head" developes again the _true_ "head" of the linux
>     kernel - akpm's tree.

If I wanted to develop something which would eventually go into 
mainline, I certainly would do it against Linus' tree. There are many 
things going on in -mm which might or might not require significant 
changes in approach to work. I think -mm is a great place to try the 
scheduler of the week, but unless some feature requires one of those, 
it's easier to start from a known base.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [BK] upgrade will be needed

[Miles Bader]

"Theodore Ts'o" <tytso@mit.edu> writes:
> The "cost" of using BK seems to be primarily more theoretical, and
> ideological, than real.

I've never used BK (not allowed to), but some things I've read about it
sound quite annoying.  For instance:

 * Every source tree contains your entire repository => massive disk usage

 * Must "unlock" files before working on them ("bk edit"); I recall
   doing this with RCS, and it was, well, a real pain.

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

Re: [BK] upgrade will be needed

[Dmitry Torokhov]

On Monday 21 February 2005 00:43, Miles Bader wrote:
> "Theodore Ts'o" <tytso@mit.edu> writes:
> > The "cost" of using BK seems to be primarily more theoretical, and
> > ideological, than real.
> 
> I've never used BK (not allowed to), but some things I've read about it
> sound quite annoying.  For instance:
> 
>  * Every source tree contains your entire repository => massive disk usage

It's not too bad as you just hardlink most of the trees to their parent.
 
>  * Must "unlock" files before working on them ("bk edit"); I recall
>    doing this with RCS, and it was, well, a real pain.

I think there is a setting to have them checked out for editing automatically.

-- 
Dmitry

N/A

[Christof Dorner]

unsubscribe linux-kernel

Re: [BK] upgrade will be needed

[Kevin P. Fleming]

Dmitry Torokhov wrote:

> It's not too bad as you just hardlink most of the trees to their parent.

Yes, and disk space is cheap.

> I think there is a setting to have them checked out for editing automatically.

Yes there is, plus most decent editors are SCCS-aware and will prompt 
for a checkout when you try edit a locked file anyway (emacs certainly 
does, without any add-on modules).

Re: [BK] upgrade will be needed

[Ed Tomlinson]

On Thursday 17 February 2005 11:58, Sean wrote:
> On Thu, February 17, 2005 11:55 am, Chris Friesen said:
> 
> > If you look at the archives, there have been a *lot* of people saying
> > very much the same thing as you.  I suspect people are getting tired of
> > giving the same responses all the time.
> >
> > Here is what Linus had to say about it a while back:
> >
> >     If people in the open-source SCM community wake up and notice that
> >     the current open-source SCM systems aren't cutting it, that's _good_.
> >     But it's absolutely NOT an excuse to use them today.  Sorry.  I use
> >     CVS at work, and I could never use it for Linux.  I took a look at
> >     subversion, and it doesn't even come close to what I wanted.
> >
> >     And I personally refuse to use inferior tools because of ideology. In
> >     fact, I will go as far as saying that making excuses for bad tools
> >     due to ideology is _stupid_, and people who do that think with their
> >     gonads, not their brains.
> 
> Chris,
> 
> Yes, I do remember that post.  But i'm not arguing from an ideological
> basis; i'm arguing on practical grounds that the price of using BK is too
> high for its supposed benefits.  I've not seen anyone else make that

Huh?  This ideology in my books.

> argument here on the list and it is something that Linus may not have
> given full consideration to.   At least the comment that you quote gives
> no consideration to it at all.

Linus has tried other SCMs.  They did not suffice.   I remember the preBK
days, when you had to post a patch half a dozen time to get it merged.  
Patches were being missed left right and center.  This changed after BK.
We _are_ getting large benefits from BK.  They may be hard to see at our
side of the keyboard - but I believe Linus when he says BK is the best 
tool for him.  That this probably will not be the case for ever.  Think
it still is for now though.

Ed Tomlinson

Re: [BK] upgrade will be needed

[Sean]

On Thu, February 17, 2005 6:25 pm, Ed Tomlinson said:

>> Yes, I do remember that post.  But i'm not arguing from an ideological
>> basis; i'm arguing on practical grounds that the price of using BK is
>> too
>> high for its supposed benefits.  I've not seen anyone else make that
>
> Huh?  This ideology in my books.

No.  It's about recognizing the needs of more people than just the few at
the top.  Besides, with a free tool at the Head, bk could continue to be
used underneath by Linus and anyone else.   And others in the community
could use their preferred tools too.

> Linus has tried other SCMs.  They did not suffice.   I remember the preBK
> days, when you had to post a patch half a dozen time to get it merged.
> Patches were being missed left right and center.  This changed after BK.
> We _are_ getting large benefits from BK.  They may be hard to see at our
> side of the keyboard - but I believe Linus when he says BK is the best
> tool for him.  That this probably will not be the case for ever.  Think
> it still is for now though.

It's not a choice between BK or nothing.   Much of the improvements you're
attributing to BK would have been realized with any other SCM system too.

Cheers,
Sean

Re: [BK] upgrade will be needed

[Lee Revell]

On Thu, 2005-02-17 at 18:32 -0500, Sean wrote:
> On Thu, February 17, 2005 6:25 pm, Ed Tomlinson said:
> > Linus has tried other SCMs.  They did not suffice.   I remember the preBK
> > days, when you had to post a patch half a dozen time to get it merged.
> > Patches were being missed left right and center.  This changed after BK.
> > We _are_ getting large benefits from BK.  They may be hard to see at our
> > side of the keyboard - but I believe Linus when he says BK is the best
> > tool for him.  That this probably will not be the case for ever.  Think
> > it still is for now though.
> 
> It's not a choice between BK or nothing.   Much of the improvements you're
> attributing to BK would have been realized with any other SCM system too.
> 

Ed did not say it was a choice between BK and nothing.  He said "Linus
has tried other SCMs.  They did not suffice."  Did you even read his
comment?

Please don't cc: me on this thread anymore, unless it's about some work
you did to bring BK functionality to a free SCM.

Lee

Re: [BK] upgrade will be needed

[Sean]

On Thu, February 17, 2005 6:54 pm, Lee Revell said:

> Ed did not say it was a choice between BK and nothing.  He said "Linus
> has tried other SCMs.  They did not suffice."  Did you even read his
> comment?

The point you missed is that it's not an honest comparison to look at the
post BK/ pre BK situation and pretend that BK was the only option that
would have produced the list of benefits that Ed outlined.  Linus has been
known to be wrong before.

> Please don't cc: me on this thread anymore, unless it's about some work
> you did to bring BK functionality to a free SCM.

No need to respond.

Cheers,
Sean

Re: [BK] upgrade will be needed

[Theodore Ts'o]

On Thu, Feb 17, 2005 at 06:32:04PM -0500, Sean wrote:
> No.  It's about recognizing the needs of more people than just the few at
> the top.  Besides, with a free tool at the Head, bk could continue to be
> used underneath by Linus and anyone else.   

If you think that, you truly do not understand the value of BK, and
why Linus chose it.

						- Ted

Re: [BK] upgrade will be needed

[Clemens Schwaighofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/18/2005 01:00 PM, Theodore Ts'o wrote:
> On Thu, Feb 17, 2005 at 06:32:04PM -0500, Sean wrote:
> 
>>No.  It's about recognizing the needs of more people than just the few at
>>the top.  Besides, with a free tool at the Head, bk could continue to be
>>used underneath by Linus and anyone else.   
> 
> 
> If you think that, you truly do not understand the value of BK, and
> why Linus chose it.

He choose it because it was the best tool to do the job at that time. It
might still be the best job to do it.

But for a normal user, who just wants to check out certain bk pulls, the
new license is not bearable. I think we need a SVN mirror here soon,
very soon.

- --
[ Clemens Schwaighofer                      -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group                           ]
[                6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp        http://www.tbwajapan.co.jp ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCFWkcjBz/yQjBxz8RAm5IAKDERXzaCeh1Qcuipp3sjZXxC7/DwgCgpl63
YgVM09sYczPMJsedObgKkLI=
=8vFK
-----END PGP SIGNATURE-----

Re: [BK] upgrade will be needed

[Sean]

On Thu, February 17, 2005 11:00 pm, Theodore Ts'o said:

> If you think that, you truly do not understand the value of BK, and
> why Linus chose it.

Hey Ted,

No, I just disagree that it was an absolute requirement or worth its cost
that so many want to completely discount.   Andrew has pretty much shown
BK is not required, he's still using patches.

Cheers,
Sean

Re: [BK] upgrade will be needed

[Ed Tomlinson]

On Friday 18 February 2005 02:26, Sean wrote:
> On Thu, February 17, 2005 11:00 pm, Theodore Ts'o said:
> 
> > If you think that, you truly do not understand the value of BK, and
> > why Linus chose it.
> 
> Hey Ted,
> 
> No, I just disagree that it was an absolute requirement or worth its cost
> that so many want to completely discount.   Andrew has pretty much shown
> BK is not required, he's still using patches.

Andrew uses BK too.  He extends its function by maintaining a set of patches
above and beyond the committed BK tree...  Ted made a really valid point.  The
people at the top _are_ _very_ _very_ important.  

There are several ways to get kernel source if _you_ do not want to use BK.  I 
use BK.  There are enough projects around that I can avoid working on a SVM 
for a year...  Thats my option though - you do not have to agree.

Ed 

Re: [BK] upgrade will be needed

[Clemens Schwaighofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/17/2005 01:57 PM, Theodore Ts'o wrote:

> Compare the number of developers, the number of overlapping
> simultaneous development trees, and the number of patches that touch
> overlapping files, and you'll begin to start to appreciate the
> difference between a system that can work for Linux, and a system that
> can working for simpler projects.

apache might be simpler, but I doubt that for gcc. But well lets see
what the gcc guys will decide.

- --
[ Clemens Schwaighofer                      -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group                           ]
[                6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp        http://www.tbwajapan.co.jp ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCFTb7jBz/yQjBxz8RAqK+AJ9qyQaqg/zQz/xt6XKpLjlJIC5u9gCbBrPg
D/3yjB5iv7HCSMtVOIZx6Xo=
=Zfsd
-----END PGP SIGNATURE-----

Re: [BK] upgrade will be needed

[Horst von Brand]

Clemens Schwaighofer <cs@tequila.co.jp> said:
> On 02/17/2005 01:57 PM, Theodore Ts'o wrote:
> > Compare the number of developers, the number of overlapping
> > simultaneous development trees, and the number of patches that touch
> > overlapping files, and you'll begin to start to appreciate the
> > difference between a system that can work for Linux, and a system that
> > can working for simpler projects.

> apache might be simpler, but I doubt that for gcc. But well lets see
> what the gcc guys will decide.

gcc has very much less developers than the kernel. It has worked for years
around CVS' shortcommings, plus being a core GNU package, it is quite
unlikely to /ever/ go for a non-oss SCM. Plus the bureaucracy (have to have
a paper signing over ownership to the FSF for any changes) make a fully
Linux-style development unlikely (and thus BK (which was designed as SCM
for the kernel) not really useful).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [BK] upgrade will be needed

[Roland Kuhn]

[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]

Hi Clemens!

On Feb 17, 2005, at 1:11 AM, Clemens Schwaighofer wrote:

> first. what kind of advantages does bk have over other svn? Seriously.
> If Apache can use it, and gcc might use it (again two very large
> projects), what makes linux so differetnt that it can't.
>
> And I don't want _anything_ from Larry. I am just pointing out, that
> this kind of legal clause is more ridicolous than understandable.
>
Well, I'm obviously not Larry, so here are my 2ct:

Subversion is superior to CVS in all respects, but that is not an 
overly strong statement. The main problem is that it is centralized in 
a way that hinders the parallel existence of development branches 
because it does not properly support the shuffling of changes back and 
forth between trees. It all works fine until you want to _partially_ 
synchronize two trees and keep the ability to continue development on 
both of them. (Been there, done that, it was a major PITA even in a 
rather small project. Works fine for my PhD thesis, though ;-) )

That said, it would of course be possible to improve the internal 
workflow of our emperor penguin if he used subversion, but the 
collaboration with others could not benefit the way it does with a 
changeset-based approach.

> Last, why can you compare cvs to bk? and not subversion, or arch? arch
> and subversion are way superiour to cvs ...
>
>> SCM is hard and not sexy, I'm afraid.
>
> yes its hard, so we have to use bk with a very strange license?
> better close the eyes and not change. What do you think is kernel
> coding? Walk in the park? Do you think all those developers say, nah I
> better use Windows or Mac OS X, because its hard and not sexy ... pah
> ... BS!
>
Linux kernel development is hard _and_ sexy :-)

Ciao,
					Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str. 85747 Garching
Telefon 089/289-12592; Telefax 089/289-12570
--
A mouse is a device used to point at
the xterm you want to type in.
Kim Alm on a.s.r.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [BK] upgrade will be needed

[Clemens Schwaighofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/17/2005 04:55 PM, Roland Kuhn wrote:

> That said, it would of course be possible to improve the internal
> workflow of our emperor penguin if he used subversion, but the
> collaboration with others could not benefit the way it does with a
> changeset-based approach.

Question is then, what about keeping a main trunk with the vanialle
release, and each dev has its own branch. now at a certain point you
have to merge them. Now where is the difference between a central rep
and a de-central one.
At day X, patches from Andrew's tree have to go to Linus tree and from
his tree into the new vanialla kernel. right?
Somehow I can't see the difference here.

> Linux kernel development is hard _and_ sexy :-)

at least something :D

- --
[ Clemens Schwaighofer                      -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group                           ]
[                6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp        http://www.tbwajapan.co.jp ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCFFEojBz/yQjBxz8RAs5rAKC1i4RuDxyi3hjnRDfcjCYyRTGbNQCgsRgc
ErnefDIDGimPjjXa8cALBQc=
=lWQ8
-----END PGP SIGNATURE-----

Re: [BK] upgrade will be needed

[Roland Kuhn]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

Hi Clemens!

On Feb 17, 2005, at 9:09 AM, Clemens Schwaighofer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/17/2005 04:55 PM, Roland Kuhn wrote:
>
>> That said, it would of course be possible to improve the internal
>> workflow of our emperor penguin if he used subversion, but the
>> collaboration with others could not benefit the way it does with a
>> changeset-based approach.
>
> Question is then, what about keeping a main trunk with the vanialle
> release, and each dev has its own branch. now at a certain point you
> have to merge them. Now where is the difference between a central rep
> and a de-central one.
> At day X, patches from Andrew's tree have to go to Linus tree and from
> his tree into the new vanialla kernel. right?
> Somehow I can't see the difference here.
>
The difference comes after the merge. Suppose Andrew didn't push 
everything to Linus. Then new patches come in, both trees change. In 
this situation it is very time consuming with subversion to work out 
the changes which still have to go from Andrew's tree to Linus' tree.

Ciao,
					Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str. 85747 Garching
Telefon 089/289-12592; Telefax 089/289-12570
--
A mouse is a device used to point at
the xterm you want to type in.
Kim Alm on a.s.r.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [BK] upgrade will be needed

[Sean]

On Thu, February 17, 2005 4:27 am, Roland Kuhn said:

> The difference comes after the merge. Suppose Andrew didn't push
> everything to Linus. Then new patches come in, both trees change. In
> this situation it is very time consuming with subversion to work out
> the changes which still have to go from Andrew's tree to Linus' tree.

Since Andrew does this all by hand now, subversion / arch / whatever could
only improve the situation.  And the kicker is that using a free system
would mean the result could be dumped into BK for those that want to use
it.   The reverse unfortunately isn't true; not because of technical
reasons, but because of license restrictions.

Sean

Re: [BK] upgrade will be needed

[Clemens Schwaighofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/17/2005 07:27 PM, Sean wrote:
> On Thu, February 17, 2005 4:27 am, Roland Kuhn said:
> 
> 
>>The difference comes after the merge. Suppose Andrew didn't push
>>everything to Linus. Then new patches come in, both trees change. In
>>this situation it is very time consuming with subversion to work out
>>the changes which still have to go from Andrew's tree to Linus' tree.
> 
> 
> Since Andrew does this all by hand now, subversion / arch / whatever could
> only improve the situation.  And the kicker is that using a free system
> would mean the result could be dumped into BK for those that want to use
> it.   The reverse unfortunately isn't true; not because of technical
> reasons, but because of license restrictions.

well I think Andrew will have tonsof small helper scripts for that. I
doubt he has time to try out various vcs ... (especially if they are so
complicated to use like arch).

- --
[ Clemens Schwaighofer                      -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group                           ]
[                6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp        http://www.tbwajapan.co.jp ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCFTecjBz/yQjBxz8RAqx5AJ9TCxTpvXkfnUbGiPM67VQsa5RVlwCeMXPR
9RPlx/090x7ALlctuvSnWo4=
=9Xst
-----END PGP SIGNATURE-----

Re: [BK] upgrade will be needed

[Juergen Stuber]

Hi Larry,

lm@bitmover.com (Larry McVoy) writes:
> The protection we need is that people don't get to
>
>     - use BK
>     - stop using BK so they can go work on another system
>     - start using BK again
>     - stop using BK so they can go work on another system
>     ...
>
> We could say that if you stop using BK and work on another system then
> you can't ever use it again.  We're not going to do that, we've already
> had to calm the fears of people who found themselves in that situation
> for their job.  

how about something akin to
'You can only use the non-paying version of BK
 if you haven't worked on another SCM-system in the last year.'

So if I stop using BK, I can immediately start working on another SCM
but I can't go back to BK immediately.

That would be much more acceptable to me, I know what I did in the past,
but I won't accept any restriction of what I can do in the future.

There would still be a problem of what to do if I get addicted to BK.


Jürgen

-- 
NO to the planned nodding through of the EU software patent directive!

Jürgen Stuber <juergen@jstuber.net>
http://www.jstuber.net/
gnupg key fingerprint = 2767 CA3C 5680 58BA 9A91  23D9 BED6 9A7A AF9E 68B4

Re: [BK] upgrade will be needed

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

On Mon, Feb 14, 2005 at 07:54:14PM +0100, Juergen Stuber wrote:
> Hi Larry,
> 
> lm@bitmover.com (Larry McVoy) writes:
> > The protection we need is that people don't get to
> >
> >     - use BK
> >     - stop using BK so they can go work on another system
> >     - start using BK again
> >     - stop using BK so they can go work on another system
> >     ...
> >
> > We could say that if you stop using BK and work on another system then
> > you can't ever use it again.  We're not going to do that, we've already
> > had to calm the fears of people who found themselves in that situation
> > for their job.  
> 
> how about something akin to
> 'You can only use the non-paying version of BK
>  if you haven't worked on another SCM-system in the last year.'

A year seems long.  Perhaps 6 months?  That should be high enough to
prevent the ping-pong that Larry wants to stop, but not so high that I
can't be employable.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

NYET! The evil stops here!
					-- Pitr
User Friendly, 6/22/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [BK] upgrade will be needed

[Matthias Andree]

On Mon, 14 Feb 2005, Juergen Stuber wrote:

> That would be much more acceptable to me, I know what I did in the past,
> but I won't accept any restriction of what I can do in the future.

> There would still be a problem of what to do if I get addicted to BK.

There'd be BK/Pro - a price list on the web for individual users might
be very helpful though. It won't be used very often but simplify the
decision process a bit.

-- 
Matthias Andree

Re: [BK] upgrade will be needed

[Juergen Stuber]

Matthias Andree <matthias.andree@gmx.de> writes:
>
> There'd be BK/Pro - a price list on the web for individual users might
> be very helpful though. It won't be used very often but simplify the
> decision process a bit.

Yes, that would be an option, I'd rather spend money than limit
my freedom.  I'd need to check out the software first,
which would be possible only if the restriction were reversed.


Jürgen

-- 
NO to the planned nodding through of the EU software patent directive!

Jürgen Stuber <juergen@jstuber.net>
http://www.jstuber.net/
gnupg key fingerprint = 2767 CA3C 5680 58BA 9A91  23D9 BED6 9A7A AF9E 68B4

Re: [BK] upgrade will be needed

[Tristan Wibberley]

On Mon, 14 Feb 2005 19:54:14 +0100, Juergen Stuber wrote:

> g BK, I can immediately start working on another SCM
> but I can't go back to BK immediately

IMHO, it should be the other way around, and more like two years, then you
can buy back time at something like 1/12th full BK license price per month
that you want less than the two years. Two years would be more appropriate
since you need to make sure that coders who've worked on the other SCM
before are well and truly out of touch with the code when they go back.
With that scheme, if you have a serious business case for writing a new
SCM *today* you just have to factor an extra cost into your plans (double
BK license), and if you want to work on an open source one, you just have
to wait while BitMover gets another two years on their head-start. Now
only people with determined plans can switch from using BK to working on
an SCM, and BitMover can get new users benefiting from their kindness and
lifting their market penetration as easily as possible.

-- 
Tristan Wibberley

Re: [BK] upgrade will be needed

[Tristan Wibberley]

On Tue, 15 Feb 2005 02:46:04 +0000, Tristan Wibberley wrote:

> On Mon, 14 Feb 2005 19:54:14 +0100, Juergen Stuber wrote:
> 
>> g BK, I can immediately start working on another SCM
>> but I can't go back to BK immediately
> 
> IMHO, it should be the other way around, and more like two years.

Hmm, I wasn't really clear here. I think that after using BK, you
shouldn't be able to work on another SCM until 2 years have past. But you
can shorten that time by paying bitmover 1/12 of a BK license for each
month you want to shorten it. That covers the problem of people needing to
switch, they just have to pay. Then the following applies:

> Two years would be more
> appropriate since you need to make sure that coders who've worked on the
> other SCM before are well and truly out of touch with the code when they
> go back. With that scheme, if you have a serious business case for
> writing a new SCM *today* you just have to factor an extra cost into
> your plans (double BK license), and if you want to work on an open
> source one, you just have to wait while BitMover gets another two years
> on their head-start. Now only people with determined plans can switch
> from using BK to working on an SCM, and BitMover can get new users
> benefiting from their kindness and lifting their market penetration as
> easily as possible.

-- 
Tristan Wibberley

Re: [BK] upgrade will be needed

[Matthias Andree]

On Mon, 14 Feb 2005, Larry McVoy wrote:

> So how would you suggest that we resolve it?  The protection we need is
> that people don't get to
> 
>     - use BK
>     - stop using BK so they can go work on another system
>     - start using BK again
>     - stop using BK so they can go work on another system
>     ...

Add a cancellation period or a relicense block to BK/Free.

For instance:

1. $licensee can cancel his license with 30 days period before end of a
   month

2. BK/Free license is not available to (1) people who have worked on a
   system essentially similar to BK in the past six weeks, (2) people
   who have had their BK/Free license terminated within the past six
   weeks for any reason other than a new BK version becoming available.

> So what do you want us to do?  This isn't a change to take stuff from
> you, it's a change that some of your peers asked us to do so they could
> use BK (and it would be nice if the people who wanted this are reading
> this thread and will speak up so it doesn't look like I'm making it up).

This is, by your leave, ridiculous. I was, so far, allowed to stop using
BK/Free on day #1 and hack non-BK SCM on day #2. I understand you don't
want users to repeat this sequence, use BK on every odd day of month and
hack non-BK SCM on every even day, and I haven't done that (I haven't
hacked SCM).

> What we've been doing so far is telling people who were worried to act as
> if there were a year long gap and they have been happy with that answer
> but they are asking for us to put it in the license so they don't have
> to depend on some email based side agreement.

So have them send a SSAE and pass that note in writing.

-- 
Matthias Andree

Re: [BK] upgrade will be needed

[Larry McVoy]

> This is, by your leave, ridiculous. I was, so far, allowed to stop using
> BK/Free on day #1 and hack non-BK SCM on day #2. I understand you don't
> want users to repeat this sequence, use BK on every odd day of month and
> hack non-BK SCM on every even day, and I haven't done that (I haven't
> hacked SCM).

That's not how others are reading it and when we requested clarification
from the legal firm we use for contracts (Fenwick&West if you care) they
said that it could well be interpreted that if you use BK you are giving
up your right to hack on another system.  That wasn't our intent but nor
is it our intent to let you go back and forth.

> > What we've been doing so far is telling people who were worried to act as
> > if there were a year long gap and they have been happy with that answer
> > but they are asking for us to put it in the license so they don't have
> > to depend on some email based side agreement.
> 
> So have them send a SSAE and pass that note in writing.

Do you have any idea how many people are using BK?  If they all asked
for this we'd be passing out more than 200 of these a day for more than
a year.  It's around one per minute.  

We either fix the license or leave it as is, we're not able to do side
agreements with everyone that asks.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[Gerold Jury]

Hi Larry
Hi Everyone

To me it looks like lot's of users (and myself) simply want to track the 
kernel development very closely.
Some are looking out for a specific bug to be fixed.
Some want to see the direction of some developments going on.
The first place a change arrives at is the bitkeeper repository.
There are others who already have an idea to contribute.
They will already know what the pros and cons of bitkeeper are, or soon find 
out.
Do you think it is possible to make a split licence that will distinguish 
between active changes and passive watching/tracking ?
The web interface does not provide the functionality for a quick overview 
about the latest changes.
It may be sufficient for a part of the people in this discussion.

Regards
Gerold

Re: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 11:24:43PM +0100, Gerold Jury wrote:
> Hi Larry
> Hi Everyone
> 
> Do you think it is possible to make a split licence that will distinguish 
> between active changes and passive watching/tracking ?

A lot of people have told us to create two products, the free product
and the commercial product, and license the free product with standard
licensing terms.  The expectation is that we would somehow make the free
product less desirable so that people bought the commercial product.

That's an excellent suggestion if our only goal is to make money, that
makes the free product sort of a teaser and the commercial product the
real deal.  However, the goal really is to help the open source
community, Linux in particular.  If we give away crippled software then
all the people who say we are just a money grubbing corporation are
more or less correct.  At that point we aren't giving away the good
stuff and it was always the goal that you got the latest and greatest
because that's what can do you the most good.

However, it sure sounds like the noisy people would be a lot happier
with a stripped down BK that didn't have as many of the restrictions.
And a possible out for even the open source users is that they buy seats
if they really need the more powerful features.  Or we could donate
some on a case by case basis.

If the hackers who are using BK can reach agreement that it would be
better if the BK they had didn't move forward unless they got commercial
seats then we could start moving towards a license on the free product
that was less restrictive.  What that would mean is that the BK you have
is basically it, we'd not advance it other than keeping it up to date
with the protocol and/or file formats of the commercial version.  If you
think BK is good enough, fast enough, done enough that you don't want
what we have coming down the pike we can go that route.

I suspect that the heavy lifters really would like a faster BK with more
features that help them get their job done but the rank and file could
care less, they just want checkin/checkout.  
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[David Lang]

Larry, I don't think he's talking about making the free bk be a striped 
down version, I think he's talking about having two different free 
versions.

version 1
what you have today with the license you need to protect yourself

version 2
a version with no check-in capability at all, all it can do is passivly 
mirror a repository to a local system and check-out a tree to a local 
system. since this version won't have any of your 'secret sauce merging 
stuff' in it it may be possible for you to use a license that doesn't need 
to include the non-compete clause.

anyone doing development would need version1, but there are a number of 
people who have bitkeeper installed but only use it to check out versions 
and really don't care about the differences between bk and cvs for this 
(and for this purpose the differences are mainly network efficiancies)

Assuming that this is techincaly posible (my memory is warning me that the 
pull from a remote repository may be a 'check-in' as things are currently 
written) I think the risk to you would that the new license would let some 
of the people who want to reverse-engineer things use this 'fetch-only' 
version and see some of the meta-data, I don't know if you can leave out 
enough of the stuff you care about to be willing to loose the rest.

As you acknowledged in your presentation this last weekend, the people at 
the bottom of the tree don't get much benifit from bitkeeper, this applies 
even more so to the people who are read-only to the system.

this does mean that there would be somehat of a commiter/non-commiter 
split, with the difference between them being those who agree to the 
non-compete license of #1 and those who don't and use #2 to have a local 
read-only copy and have to use normal patches to submit changes up the 
tree.

David Lang

  On Mon, 14 Feb 2005 lm@bitmover.com wrote:

> Date: Mon, 14 Feb 2005 14:57:04 -0800
> From: lm@bitmover.com
> To: Gerold Jury <gjury@inode.at>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
>     Jeff Sipek <jeffpc@optonline.net>,
>     Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: Re: [BK] upgrade will be needed
> 
> On Mon, Feb 14, 2005 at 11:24:43PM +0100, Gerold Jury wrote:
>> Hi Larry
>> Hi Everyone
>>
>> Do you think it is possible to make a split licence that will distinguish
>> between active changes and passive watching/tracking ?
>
> A lot of people have told us to create two products, the free product
> and the commercial product, and license the free product with standard
> licensing terms.  The expectation is that we would somehow make the free
> product less desirable so that people bought the commercial product.
>
> That's an excellent suggestion if our only goal is to make money, that
> makes the free product sort of a teaser and the commercial product the
> real deal.  However, the goal really is to help the open source
> community, Linux in particular.  If we give away crippled software then
> all the people who say we are just a money grubbing corporation are
> more or less correct.  At that point we aren't giving away the good
> stuff and it was always the goal that you got the latest and greatest
> because that's what can do you the most good.
>
> However, it sure sounds like the noisy people would be a lot happier
> with a stripped down BK that didn't have as many of the restrictions.
> And a possible out for even the open source users is that they buy seats
> if they really need the more powerful features.  Or we could donate
> some on a case by case basis.
>
> If the hackers who are using BK can reach agreement that it would be
> better if the BK they had didn't move forward unless they got commercial
> seats then we could start moving towards a license on the free product
> that was less restrictive.  What that would mean is that the BK you have
> is basically it, we'd not advance it other than keeping it up to date
> with the protocol and/or file formats of the commercial version.  If you
> think BK is good enough, fast enough, done enough that you don't want
> what we have coming down the pike we can go that route.
>
> I suspect that the heavy lifters really would like a faster BK with more
> features that help them get their job done but the rank and file could
> care less, they just want checkin/checkout.
> --
> ---
> Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 03:23:47PM -0800, David Lang wrote:
> Larry, I don't think he's talking about making the free bk be a striped 
> down version, I think he's talking about having two different free 
> versions.

Leaving aside the $600K/year or so it would cost us to do that...

> this does mean that there would be somehat of a commiter/non-commiter 
> split, with the difference between them being those who agree to the 
> non-compete license of #1 and those who don't and use #2 to have a local 
> read-only copy and have to use normal patches to submit changes up the 
> tree.

And how does the CVS gateway not provide this today?  We effectively
have exactly what you are describing.  And long ago I offered what I
called the tarball + patch server with an open source client for all
trees on bkbits.net - here it is:  http://lkml.org/lkml/2003/12/14/47
If people had stopped flaming long enough to look at that it would 
be installed on bkbits today and any repo hosted there would have an
automatic real-time gateway with no license problems.  Heck, we could
even export the changeset comments into ChangeLog as Keith suggested
here: http://lkml.org/lkml/2003/12/14/92 .  

People didn't seem interested and I came with the conclusion, rightly or
wrongly, that the vast majority of the people who did real work didn't
care about the license and the noisy people just wanted to pick a fight.
If I was wrong and this is valuable I can look into putting it up on
bkbits.net.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[David Lang]

On Mon, 14 Feb 2005 lm@bitmover.com wrote:

>> this does mean that there would be somehat of a commiter/non-commiter
>> split, with the difference between them being those who agree to the
>> non-compete license of #1 and those who don't and use #2 to have a local
>> read-only copy and have to use normal patches to submit changes up the
>> tree.
>
> And how does the CVS gateway not provide this today?  We effectively
> have exactly what you are describing.  And long ago I offered what I
> called the tarball + patch server with an open source client for all
> trees on bkbits.net - here it is:  http://lkml.org/lkml/2003/12/14/47
> If people had stopped flaming long enough to look at that it would
> be installed on bkbits today and any repo hosted there would have an
> automatic real-time gateway with no license problems.  Heck, we could
> even export the changeset comments into ChangeLog as Keith suggested
> here: http://lkml.org/lkml/2003/12/14/92 .

the advantage over CVS would be the reduced network useage (both server 
side and client side), but that's not worth the development costs you are 
quoting.

since I don't have any problem with your license I had forgotten about 
that other option. I was just trying to clarify what looked like a 
misunderstanding of what was being asked and exploring options to reduce 
the flaming.

> People didn't seem interested and I came with the conclusion, rightly or
> wrongly, that the vast majority of the people who did real work didn't
> care about the license and the noisy people just wanted to pick a fight.
> If I was wrong and this is valuable I can look into putting it up on
> bkbits.net.

unfortunantly, you are probably right :-(

David Lang


-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [BK] upgrade will be needed

[Olivier Galibert]

On Mon, Feb 14, 2005 at 04:03:43PM -0800, Larry McVoy wrote:
> And how does the CVS gateway not provide this today?

The CVS gateway does not reach the rest of bkbits.net.  For instance
the ipw2200 tree since they miss some of the files in their tarball
distribution.


> And long ago I offered what I
> called the tarball + patch server with an open source client for all
> trees on bkbits.net

Funnily enough the NWL probably isn't open-source because of the first
clause.  But frankly, it's irrelevant.


> People didn't seem interested and I came with the conclusion, rightly or
> wrongly, that the vast majority of the people who did real work didn't
> care about the license and the noisy people just wanted to pick a fight.

I read your mail as "you'll get that if and only the usual band stops
whining", which obviously won't happen.  Maybe I was wrong, I only
know that at that point I can't get useful files from free projects
hosted on bkbits if they're not the kernel itself.  Your extension
would indeed help.

  OG.

Re: [BK] upgrade will be needed

[Gerold Jury]

>if they really need the more powerful features.  Or we could donate
>some on a case by case basis.
>
>If the hackers who are using BK can reach agreement that it would be
>better if the BK they had didn't move forward unless they got commercial
>seats then we could start moving towards a license on the free product
>that was less restrictive.  What that would mean is that the BK you have

I want to pay the fee for Linus and Alan.

Regards
Gerold

Re: [BK] upgrade will be needed

[Alexandre Oliva]

On Feb 14, 2005, Gerold Jury <gjury@inode.at> wrote:

>> if they really need the more powerful features.  Or we could donate
>> some on a case by case basis.
>> 
>> If the hackers who are using BK can reach agreement that it would be
>> better if the BK they had didn't move forward unless they got commercial
>> seats then we could start moving towards a license on the free product
>> that was less restrictive.  What that would mean is that the BK you have

> I want to pay the fee for Linus and Alan.

I'd like to pay the fee to have Linus' license to use BK revoked.  But
I probably can't afford it, oh well :-)

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: [BK] upgrade will be needed

[Alan Cox]

> > I want to pay the fee for Linus and Alan.
> 
> I'd like to pay the fee to have Linus' license to use BK revoked.  But
> I probably can't afford it, oh well :-)

Just write an SCM file system for the kernel and submit it to Linus.

As to buying me a license, don't bother, and besides who knows what
restrictions would magically appear in the next release Larry did. While
Larry may well be a very friendly and well intentioned devil I'm still
not making pacts with devils 8)

The real fix is to replace BK with something free and better, but thats
*not* a trivial task.

Re: [BK] upgrade will be needed

[Pavel Machek]

Hi!

> >> if they really need the more powerful features.  Or we could donate
> >> some on a case by case basis.
> >> 
> >> If the hackers who are using BK can reach agreement that it would be
> >> better if the BK they had didn't move forward unless they got commercial
> >> seats then we could start moving towards a license on the free product
> >> that was less restrictive.  What that would mean is that the BK you have
> 
> > I want to pay the fee for Linus and Alan.
> 
> I'd like to pay the fee to have Linus' license to use BK revoked.  But
> I probably can't afford it, oh well :-)

Easy, start working for OSDL, then start hacking arch or
whatever. Puff, you are his coworker, you are competing with Larry,
Linus license goes away.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [BK] upgrade will be needed

[Alexandre Oliva]

On Feb 16, 2005, Pavel Machek <pavel@suse.cz> wrote:

>> > I want to pay the fee for Linus and Alan.

>> I'd like to pay the fee to have Linus' license to use BK revoked.  But
>> I probably can't afford it, oh well :-)

> Easy, start working for OSDL, then start hacking arch or
> whatever. Puff, you are his coworker, you are competing with Larry,
> Linus license goes away.

Hey, cool!  The nice thing is that I probably don't even have to start
hacking anything, I already (pretend to) maintain GNU CVS Utilities.
Can I volunteer to maintain is for OSDL, at no charge?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: [BK] upgrade will be needed

[Geert Uytterhoeven]

On Thu, 17 Feb 2005, Pavel Machek wrote:
> > >> if they really need the more powerful features.  Or we could donate
> > >> some on a case by case basis.
> > >> 
> > >> If the hackers who are using BK can reach agreement that it would be
> > >> better if the BK they had didn't move forward unless they got commercial
> > >> seats then we could start moving towards a license on the free product
> > >> that was less restrictive.  What that would mean is that the BK you have
> > 
> > > I want to pay the fee for Linus and Alan.
> > 
> > I'd like to pay the fee to have Linus' license to use BK revoked.  But
> > I probably can't afford it, oh well :-)
> 
> Easy, start working for OSDL, then start hacking arch or
> whatever. Puff, you are his coworker, you are competing with Larry,
> Linus license goes away.

I don't know whether the kernel hackers that work for IBM use the `free'
version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and
there's a problem...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [BK] upgrade will be needed

[Pavel Machek]

Hi!

> > Easy, start working for OSDL, then start hacking arch or
> > whatever. Puff, you are his coworker, you are competing with Larry,
> > Linus license goes away.
> 
> I don't know whether the kernel hackers that work for IBM use the `free'
> version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and
> there's a problem...

Actually someone should show the license agreement to IBM (and Novell,
for that matter) lawyers. I guess next thing would be company-wide
search-and-destroy aimed at bitkeeper ;-).
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [BK] upgrade will be needed

[Citizen Number 24655]

On Thu, Feb 17, 2005 at 01:36:03PM +0100, Citizen Number 52642 wrote:
> > > Easy, start working for OSDL, then start hacking arch or
> > > whatever. Puff, you are his coworker, you are competing with Larry,
> > > Linus license goes away.
> > 
> > I don't know whether the kernel hackers that work for IBM use the `free'
> > version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and
> > there's a problem...
> 
> Actually someone should show the license agreement to IBM (and Novell,
> for that matter) lawyers. I guess next thing would be company-wide
> search-and-destroy aimed at bitkeeper ;-).

I think this attitude is completely rediculous.

What you are suggesting is taking away peoples right to choose to use
BitKeeper if they decide that it fits what they want to use it for,
and that they can live with the license terms (and/or have a special
agreement with BitMover for that purpose.)

Sure, that sounds exactly like a free world, Citizen Number 52642.

-- 
Citizen Number 24655
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [BK] upgrade will be needed

[Theodore Ts'o]

On Thu, Feb 17, 2005 at 10:46:41AM +0100, Geert Uytterhoeven wrote:
> I don't know whether the kernel hackers that work for IBM use the `free'
> version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and
> there's a problem...

No, there's not a problem.

						- Ted

Re: [BK] upgrade will be needed

[Florian Weimer]

* Geert Uytterhoeven:

>> Easy, start working for OSDL, then start hacking arch or
>> whatever. Puff, you are his coworker, you are competing with Larry,
>> Linus license goes away.
>
> I don't know whether the kernel hackers that work for IBM use the
> `free' version of BK or not, but if they do, s/OSDL/IBM/ and
> s/arch/ClearCase/ and there's a problem...

No, there isn't.  Bitmover can choose freely against whom they try to
enforce their copyright licenses.  Copyright law is not like trademark
law.  You can selectively enforce your rights without risking
dilution.

Re: [BK] upgrade will be needed

[Andrea Arcangeli]

On Mon, Feb 14, 2005 at 12:05:44PM -0800, Larry McVoy wrote:
> That's not how others are reading it and when we requested clarification
> from the legal firm we use for contracts (Fenwick&West if you care) they
> said that it could well be interpreted that if you use BK you are giving
> up your right to hack on another system.  That wasn't our intent but nor

You know I'm not a lawyer but that's exactly the way I read it too:

	http://lkml.org/lkml/2004/10/25/224
	http://lkml.org/lkml/2004/10/25/400
	http://lkml.org/lkml/2004/10/25/249

I've been too harsh in the past on this, but the no time limit was
unbearable to me, and finally some sanity showed up today and things
become bearable for the first time ever as far as I'm concerned.

Now it seems that many folks misunderstood the old licence if they're
complaining about the licence change. Complaints about the new licence
are a no sense as far as I can see.

I'm only amazed you didn't clarify this earlier if your intention was
really to allow hacking on other systems after a certain amount of time.
You had ton of chances to clarify it before the layers lined things up,
including in answer to the above messages.  Anyway I don't care since a
clarification by email wouldn't been enough as far as I was concerned,
so I'm glad eventually the licence is changing.

A big thanks to Fenwick&West from my part.

Re: [BK] upgrade will be needed

[Ed Tomlinson]

On Monday 14 February 2005 10:40, Larry McVoy wrote:
> On Mon, Feb 14, 2005 at 10:08:20AM -0500, Jeff Sipek wrote:
> > On Mon, Feb 14, 2005 at 01:08:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy <lm@bitmover.com> wrote:
> > > > is to clarify the non-compete stuff.  We've had some people who have
> > > > indicated that they believed that if they used BK they were agreeing
> > > > that they would never work on another SCM system.  We can see how it
> > > > is possible that people would interpret the license that way but that
> > > > wasn't our intent.  What we would like to do is change the language to
> > > > say that if you use BK you are agreeing that you won't work on another
> > > > SCM for 1 year after you stop using BK.  But after that you would be
> > > 
> > > I don't even plan working on some SCM system, but being
> > > tainted for 1 year for just *using* BK is not worth the price IMHO.
> > 
> > I agree, the price is just too high. No matter how much I like BK, I
> > would give it up.
> 
> The way some people are reading the license the price is even higher,
> they think it is a forever tainted license as it stands today.  I've had
> specific requests to clarify this part of the license.
> 
> So how would you suggest that we resolve it?  The protection we need is
> that people don't get to

How about just reversing it.  If you work on another scm you cannot use
_free_ bk for 1 year after you stop. 

Ed Tomlinson


>     - use BK
>     - stop using BK so they can go work on another system
>     - start using BK again
>     - stop using BK so they can go work on another system
>     ...
> 
> We could say that if you stop using BK and work on another system then
> you can't ever use it again.  We're not going to do that, we've already
> had to calm the fears of people who found themselves in that situation
> for their job.  
> 
> So what do you want us to do?  This isn't a change to take stuff from
> you, it's a change that some of your peers asked us to do so they could
> use BK (and it would be nice if the people who wanted this are reading
> this thread and will speak up so it doesn't look like I'm making it up).
> 
> What we've been doing so far is telling people who were worried to act as
> if there were a year long gap and they have been happy with that answer
> but they are asking for us to put it in the license so they don't have
> to depend on some email based side agreement.
> 
> It would be nice if you could talk this over amongst yourselves and
> suggest an answer.  I can see why you think it is a bad change, I'm hoping
> that you can see why other people may want us to make this sort of change.
> Maybe if you think about it a bit you'll come up with a better solution.
> Or maybe we will.  Either way, I can't be very involved in the process,
> I'm taking off for a week long vacation starting Wednesday and I won't
> have email access.  Which will be a good way to make sure that if this 
> turns into a flame war I won't be prolonging it.

Re: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 09:13:14PM -0500, Ed Tomlinson wrote:
> > The way some people are reading the license the price is even higher,
> > they think it is a forever tainted license as it stands today.  I've had
> > specific requests to clarify this part of the license.
> > 
> > So how would you suggest that we resolve it?  The protection we need is
> > that people don't get to
> 
> How about just reversing it.  If you work on another scm you cannot use
> _free_ bk for 1 year after you stop. 

Hi Ed, thanks for the thought.  We've discussed this idea before with
some managers of open source developers and found that no matter which
one we pick some people don't like it.  People tend to cluster up based on
whether they value working on $SCM more or using BK more.  If they want to
preserve the ability to move people to working on competing products then
they would like the option you suggested.  If they are more interested
in using BK then they would prefer the other way.  The people we spoke
with were far more interested in the ability to move people onto BK when
they needed to.

But it's a good idea and we'd certainly be willing to flip to your way
on a case by case basis.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[Paul Jackson]

Another variation - allow _one_ flip, either way, into or out of BK.
But each flip sets a one year timer within which you can't reverse flip.

 ... just brainstorming ...

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.650.933.1373, 1.925.600.0401

Re: [BK] upgrade will be needed

[Ed Tomlinson]

On Monday 14 February 2005 21:40, Larry McVoy wrote:
> On Mon, Feb 14, 2005 at 09:13:14PM -0500, Ed Tomlinson wrote:
> > > The way some people are reading the license the price is even higher,
> > > they think it is a forever tainted license as it stands today.  I've had
> > > specific requests to clarify this part of the license.
> > > 
> > > So how would you suggest that we resolve it?  The protection we need is
> > > that people don't get to
> > 
> > How about just reversing it.  If you work on another scm you cannot use
> > _free_ bk for 1 year after you stop. 
> 
> Hi Ed, thanks for the thought.  We've discussed this idea before with
> some managers of open source developers and found that no matter which
> one we pick some people don't like it.  People tend to cluster up based on
> whether they value working on $SCM more or using BK more.  If they want to
> preserve the ability to move people to working on competing products then
> they would like the option you suggested.  If they are more interested
> in using BK then they would prefer the other way.  The people we spoke
> with were far more interested in the ability to move people onto BK when
> they needed to.
> 
> But it's a good idea and we'd certainly be willing to flip to your way
> on a case by case basis.

Thanks.  My though was that this was less restrictive as there is an option to
purchase a nonfree licence in there and sales are almost always a good thing.

<grin>
Ed

Re: [BK] upgrade will be needed

[Alexandre Oliva]

On Feb 15, 2005, lm@bitmover.com (Larry McVoy) wrote:

> The people we spoke with were far more interested in the ability to
> move people onto BK when they needed to.

They can always pay for the non-free license to get that, I suppose.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: [BK] upgrade will be needed

[Anton Ertl]

Alexandre Oliva writes:
>They can always pay for the non-free license to get that, I suppose.

As far as I understand it, there are only non-free licences for
Bitkeeper.  For one you pay with money, for the other with freedom.

While I am posting in this thread, I have a few questions to Larry
McVoy:

- You wrote that you could not develop Bitkeeper as free software,
because it is economically not viable.  You also write that you put
the non-compete clause in the pay-with-freedom license, because you
don't want to see a free clone of bitkeeper eat your business.  So do
you consider a free Bitkeeper-like system economically viable after
all?

- You say that all information is there, in the form of the patches.
Could Bitkeeper reconstruct the Linux tree(s) from the patches alone?

  - anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

Re: [BK] upgrade will be needed

[Mws]

[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]

On Monday 14 February 2005 03:08, Larry McVoy wrote:
> This is a heads up that the BK tree for the kernel is currently at 59,000
> changesets give or take a few.  The BK that you are using uses unsigned
> shorts for the internal names of each delta which means you folks are
> about 100 days away from things no longer working.
> 
> The good news is that the openlogging tree for the kernel has 135,000
> changesets so we've obviously long since fixed this problem.
> 
> The bad news is that you will need to upgrade your BK binary in order
> to pass over the 64K changeset boundary.  The data is stored on disk in
> ascii so it doesn't matter if you upgrade until you hit the problem but
> sooner or later you will need to upgrade.
> 
> We'll get the fix into bk-3.2.4 which should be out by the end of the
> month.  When we release that we'll send out notice and it would be good
> if people gave it a try and let us know if they hit issues because in a
> couple of months everyone is going to have to upgrade.
> 
> It's possible that we'll be changing the BK license to conform more with
> our commercial license but we won't do that without running it by Linus &
> Co to make sure that it's acceptable.  One change we'd like to make there
> is to clarify the non-compete stuff.  We've had some people who have
> indicated that they believed that if they used BK they were agreeing
> that they would never work on another SCM system.  We can see how it
> is possible that people would interpret the license that way but that
> wasn't our intent.  What we would like to do is change the language to
> say that if you use BK you are agreeing that you won't work on another
> SCM for 1 year after you stop using BK.  But after that you would be
> able to hack on anything that you wanted.  That was more of what we
> had in mind in the first place but we didn't make it clear.  If you all
> thought that using BK meant you had no right to hack on SCM ever again,
> that's just not fair.  We need to protect our IP but you should have
> the right to choose to go hack SCM if that's what you (our first choice
> is that you came and worked here, we really like kernel hackers, but if
> you don't want to that's cool too).
Hi, 

do you mean "if you use BK you are agreeing that you won't work on another
SCM for 1 year after you stop using BK." for the kernel tree and developers or in general?

i think this statement is just a kind of trying the MicrosoftBeingTheOneAndOnly way.
it's a kind of extortion - use bk or die :/
if it is really being that way - say goodbye to bk as soon as possible.

regards
mws

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [BK] upgrade will be needed

[Steven Rostedt]

On Mon, 2005-02-14 at 14:13 +0100, Mws wrote:
> On Monday 14 February 2005 03:08, Larry McVoy wrote:

> > wasn't our intent.  What we would like to do is change the language to
> > say that if you use BK you are agreeing that you won't work on another
> > SCM for 1 year after you stop using BK.  But after that you would be
> > able to hack on anything that you wanted.  That was more of what we
> > had in mind in the first place but we didn't make it clear.  If you all
> > thought that using BK meant you had no right to hack on SCM ever again,
> > that's just not fair.  We need to protect our IP but you should have
> > the right to choose to go hack SCM if that's what you (our first choice
> > is that you came and worked here, we really like kernel hackers, but if
> > you don't want to that's cool too).
> Hi, 
> 
> do you mean "if you use BK you are agreeing that you won't work on another
> SCM for 1 year after you stop using BK." for the kernel tree and developers or in general?

IANAL, but I've talked to lawyers about clauses like this with
employment. Most of these clauses are too restrictive and are not
enforcible. But I've never heard of a non-compete clause to USE a
product. Only if you work on something.  I'll have to have another talk
with my lawyer, but I am pretty sure that you can't prevent someone from
employment just because they used a product.  I can understand if you
were employed by bitmover, or signed an NDA to look at the code. But
just the act of using it is ridicules.  Can you see Ford Motors telling
someone that you can't go work for GM if you drive a Ford?

FYI,
 What my lawyer told me about non-compete clauses (in the work place),
was that if they prevent you from getting employment in your skill set,
and your only other choice is basically to flip burgers, then they are
not enforcible (this is in respect to the USA, void where prohibited).

-- Steve
 

Re: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote:
> Can you see Ford Motors telling
> someone that you can't go work for GM if you drive a Ford?

You paid for the Ford.  Suppose Ford offered to give you the car but
said if you take it then you can't go work at GM because this car is
ahead of their technology.

See the difference?  It's one thing if you plunked your money down and
took the standard license or a negotiated license.  You are getting 
an expensive product and not paying any money for it.  The payment is
the terms you agree to in the license and the obligations of those
terms.  That payment may be unacceptable to you, which is your choice.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [BK] upgrade will be needed

[Marcin Dalecki]

On 2005-02-14, at 17:00, Larry McVoy wrote:

> On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote:
>> Can you see Ford Motors telling
>> someone that you can't go work for GM if you drive a Ford?
>
> You paid for the Ford.  Suppose Ford offered to give you the car but
> said if you take it then you can't go work at GM because this car is
> ahead of their technology.
>
> See the difference?  It's one thing if you plunked your money down and
> took the standard license or a negotiated license.  You are getting
> an expensive product and not paying any money for it.  The payment is
> the terms you agree to in the license and the obligations of those
> terms.  That payment may be unacceptable to you, which is your choice.

More and more you are simply giving yourself the image of dishonesty.
Yours supposed "license terms" sound somehow like the advertisement 
where you are
supposed to be entitled for a "big prize", which you will be
able to receive immediately after you order some additional crap for 
real
money.

Re: [BK] upgrade will be needed

[kernel]

On Mon, 2005-02-14 at 11:00, Larry McVoy wrote:
> On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote:
> > Can you see Ford Motors telling
> > someone that you can't go work for GM if you drive a Ford?
> 

Actually, when I worked at Goodyear their policy was all
execs/management had to drive an American car with Goodyear tires to
work.  In mahogany row I never saw so many Vettes, Prowlers, and Vipers 
:)

To work at Goodyear and be in that position you had to ride on the wings
of Goodyear.  Everyone did it, complaints and all.

-fd 

Re: [BK] upgrade will be needed

[Pavel Machek]

On Po 14-02-05 08:00:27, Larry McVoy wrote:
> On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote:
> > Can you see Ford Motors telling
> > someone that you can't go work for GM if you drive a Ford?
> 
> You paid for the Ford.  Suppose Ford offered to give you the car but
> said if you take it then you can't go work at GM because this car is
> ahead of their technology.

This is irelevant.

Your license is illegal in big part of the world. You can just
download bitkeeper and reverse engineer it in order to interoperate
with it, no matter what Larry says; just check your local laws.

To make the analogy: "You can stand on the street, giving people free
Pepsi and telling them they are not allowed to drink Cola if they take
Pepsi from you. And they can safely take Pepsi from you, drink it and
laugh at you." Try it.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [BK] upgrade will be needed

[Andrea Arcangeli]

On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote:
> were employed by bitmover, or signed an NDA to look at the code. But
> just the act of using it is ridicules.  Can you see Ford Motors telling
> someone that you can't go work for GM if you drive a Ford?

Your point makes sense to me too, but really, this 1 year delay is
nothing compared to the previous status, so this is a great improvement.

The previous licence was not enforceable in Germany and I guess in Italy
too, but really seeing so many other people using a product with such a
licence and without any care (even if void) was unbearable to me.

Now the new licence may still not be enforceable, but I don't care
anymore, because even if it's enforceable by bad luck, it would be
bearable to wait 1 year. Switching SCM is a costly operation regardless.
This time limit has been declared for the first time ever, and this is a
great news, so now the FUD is over.

Re: [BK] upgrade will be needed

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote:
> Something that unintentionally started a flamewar.

Well, we just went through another round of 'BK sucks' and 'BK sucks, we need 
to switch to something else'.

Sans the flamewar, are there any options? CVS and SVN are out because they do 
not support 'off server' branches (arch and darcs do). Darcs would probably 
be the best choice because its easy to use, and the darcs team almost has a 
working linux-kernel import script (originally designed to just test darcs 
with a huge repo, but provides a mostly working linux tree).

So, without the flamewar, what is everyone's opinion on this? 

-- 
Patrick "Diablo-D3" McFarland || unknown@panax.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [darcs-users] Re: [BK] upgrade will be needed

[Tupshin Harper]

Patrick McFarland wrote:

>On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote:
>  
>
>>Something that unintentionally started a flamewar.
>>    
>>
>
>Well, we just went through another round of 'BK sucks' and 'BK sucks, we need 
>to switch to something else'.
>
>Sans the flamewar, are there any options? CVS and SVN are out because they do 
>not support 'off server' branches (arch and darcs do). Darcs would probably 
>be the best choice because its easy to use, and the darcs team almost has a 
>working linux-kernel import script (originally designed to just test darcs 
>with a huge repo, but provides a mostly working linux tree).
>
>So, without the flamewar, what is everyone's opinion on this? 
>  
>
Speaking as somebody that uses Darcs evey day, my opinion is that the 
future of OSS SCM will be something like arch or darcs but that neither 
are ready for projects the size of the linux kernel yet. Darcs is 
definitely way too slow for really large projects (though great for 
small to medium sized ones). Last I checked, Arch was still too slow in 
some areas, though that might have changed in recent months. Also, many 
people, me included, find the usability of arch to be from ideal.

My hope and expectation is that Arch and Darcs will both improve their 
performance, features, and usability and that in the not too distant 
future both of them will be viable alternatives for large scale source 
tree management.

The important thing for the health of the SCM ecosystem is that there be 
ways to losslessly convert and interoperate between them as well as 
between legacy/centralized systems such as CVS and SVN as well as with BK.

-Tupshin

Re: [darcs-users] Re: [BK] upgrade will be needed

[Sean]

On Thu, February 17, 2005 9:24 pm, Tupshin Harper said:

Hi Tupshin,

> Speaking as somebody that uses Darcs evey day, my opinion is that the
> future of OSS SCM will be something like arch or darcs but that neither
> are ready for projects the size of the linux kernel yet. Darcs is
> definitely way too slow for really large projects (though great for
> small to medium sized ones). Last I checked, Arch was still too slow in
> some areas, though that might have changed in recent months. Also, many
> people, me included, find the usability of arch to be from ideal.
>
> My hope and expectation is that Arch and Darcs will both improve their
> performance, features, and usability and that in the not too distant
> future both of them will be viable alternatives for large scale source
> tree management.

Falling into the same category probably is svk, although it's less mature
than the options you cite.

> The important thing for the health of the SCM ecosystem is that there be
> ways to losslessly convert and interoperate between them as well as
> between legacy/centralized systems such as CVS and SVN as well as with
> BK.

Amen.

Thanks,
Sean

Re: [darcs-users] Re: [BK] upgrade will be needed

[Andrea Arcangeli]

On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote:
> small to medium sized ones). Last I checked, Arch was still too slow in 
> some areas, though that might have changed in recent months. Also, many 

IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the
backend and a single file for the changesets and with sane parameters
conventions miming SVN. The internal algorithms of arch seems the most
advanced possible. It's just the interface and the fs backend that's so
bad and doesn't compress in the backups either.  SVN bsddb doesn't
compress either by default, but at least the new fsfs compresses pretty
well, not as good as CVS, but not as badly as bsddb and arch either.

I may be completely wrong, so take the above just as a humble
suggestion.

darcs scares me a bit because it's in haskell, I don't believe very much
in functional languages for compute intensive stuff, ram utilization
skyrockets sometime (I wouldn't like to need >1G of ram to manage the
tree). Other languages like python or perl are much slower than C/C++
too but at least ram utilization can be normally dominated to sane
levels with them and they can be greatly optimized easily with C/C++
extensions of the performance critical parts.

Re: [darcs-users] Re: [BK] upgrade will be needed

[Tomasz Zielonka]

On Fri, Feb 18, 2005 at 10:09:00AM +0100, Andrea Arcangeli wrote:
> darcs scares me a bit because it's in haskell, I don't believe very much
> in functional languages for compute intensive stuff, ram utilization
> skyrockets sometime (I wouldn't like to need >1G of ram to manage the
> tree).

AFAICS, most of memory related problems in darcs are not necessarily a
result of using Haskell.

> Other languages like python or perl are much slower than C/C++ too but
> at least ram utilization can be normally dominated to sane levels with
> them and they can be greatly optimized easily with C/C++ extensions of
> the performance critical parts.

With those languages, you often have no other choice than resorting to
C. GHC is quite a good compiler and I've often been able to get my
programs run almost as fast as programs written in C++ - however, if I
were to write those programs in C++, I would never do that, despite
being quite a good C++ programmer.

Also, in Haskell you can use extensions written in C, as easily or even
easier than in Python or Perl (I've done this in Perl, heard the battle
stories about C extensions in Python). Haskell's FFI is quite good,
there are also many supporting tools.

Best regards
Tomasz

-- 
Szukamy programisty C++ i Haskell'a: http://tinyurl.com/5mw4e

Re: [darcs-users] Re: [BK] upgrade will be needed

[Erik Bågfors]

On Fri, 18 Feb 2005 10:09:00 +0100, Andrea Arcangeli <andrea@suse.de> wrote:
> On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote:
> > small to medium sized ones). Last I checked, Arch was still too slow in
> > some areas, though that might have changed in recent months. Also, many
> 
> IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the
> backend and a single file for the changesets and with sane parameters
> conventions miming SVN.

RCS/SCCS format doesn't make much sence for a changeset oriented SCM.

/Erik

Re: [darcs-users] Re: [BK] upgrade will be needed

[Andrea Arcangeli]

On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
> RCS/SCCS format doesn't make much sence for a changeset oriented SCM.

The advantage it will provide is that it'll be compact and a backup will
compress at best too. Small compressed tarballs compress very badly
instead, it wouldn't be even comparable. Once the thing is very compact
it has a better chance to fit in cache, and if it fits in cache
extracting diffs from each file will be very fast. Once it'll be compact
the cost of a changeset will be diminished allowing it to scale better
too.

Now it's true new disks are bigger, but they're not much faster, so if
the size of the repository is much larger, it'll be much slower to
checkout if it doesn't fit in cache. And if it's smaller it has better
chances of fitting in cache too.

The thing is, RCS seems a space efficient format for storing patches,
and it's efficient at extracting them too (plus it's textual so it's not
going to get lost info even if something goes wrong).

The whole linux-2.5 CVS is 500M uncompressed and 75M tar.bz2 compressed.

My suggestion is to convert _all_ dozen thousand changesets to arch or
SVN and then compare the size with CVS (also the compressed size is
interesting for backups IMHO). Unfortunately I know nothing about darcs
yet (except it eats quite some memory ;)

Re: [darcs-users] Re: [BK] upgrade will be needed

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 5780 bytes --]

On Friday 18 February 2005 07:50 am, Andrea Arcangeli wrote:
> On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
> > RCS/SCCS format doesn't make much sence for a changeset oriented SCM.
>
> The advantage it will provide is that it'll be compact and a backup will
> compress at best too. Small compressed tarballs compress very badly
> instead, it wouldn't be even comparable. Once the thing is very compact
> it has a better chance to fit in cache, and if it fits in cache
> extracting diffs from each file will be very fast. Once it'll be compact
> the cost of a changeset will be diminished allowing it to scale better
> too.

In the case of darcs, RCS/SCCS works exactly opposite of how darcs does. By 
using it's super magical method, it represents how code is written and how it 
changes (patch theory at its best). You can clearly see the direction code is 
going, where it came from, and how it relates to other patches.

Sure, you can do this with RCS/SCCS style versioning, but whats the point? It 
is inefficient, and backwards.

> Now it's true new disks are bigger, but they're not much faster, so if
> the size of the repository is much larger, it'll be much slower to
> checkout if it doesn't fit in cache. And if it's smaller it has better
> chances of fitting in cache too.

Thats all up to how the versioning system is written. Darcs developers are 
working in a checkpoint system to allow you to just grab the newest stuff, 
and automatically grab anything else you need, instead of just grabbing 
everything. In the case of the darcs linux repo, no one wants to download 600 
megs or so of changes.

> The thing is, RCS seems a space efficient format for storing patches,
> and it's efficient at extracting them too (plus it's textual so it's not
> going to get lost info even if something goes wrong).

It may not even be space efficient. Code ultimately is just code, and changes 
ultimately are changes. RCS isn't magical, and its far from it. Infact, the 
format darcs uses probably stores more code in less space, but don't quote me 
on that.

> The whole linux-2.5 CVS is 500M uncompressed and 75M tar.bz2 compressed.

The darcs repo which has the entire history since at least the start of 2.4 
(iirc anyways) to *now* is around 600 to 700. 

> My suggestion is to convert _all_ dozen thousand changesets to arch or
> SVN and then compare the size with CVS (also the compressed size is
> interesting for backups IMHO). Unfortunately I know nothing about darcs
> yet (except it eats quite some memory ;)

My suggestion is to convert _all_ dozen thousand changesets to darcs, and then 
compare the size with CVS. And no, darcs doesn't eat that much memory for the 
amount of work its doing. (And yes, they are working on that).

The only thing you haven't brought up is the whole "omgwtfbbq! BK sucks, lets 
switch to SVN or Arch!" thing everyone else in the known universe is doing. 
BK isn't clearly inferior or superior to SVN or Arch or Darcs (and the same 
goes for SVN vs Arch vs Darcs).

(Start Generic BK Thread On LKML Rant)

Dear Everyone,

I think if Linus is happy with BK, he should stick with it. His opinion 
ultimately trumps all of ours because he does all the hard maintainership 
work, and we don't. The only guy that gets to bitch about how much a 
versioning system sucks is the maintainer of a project (unless its CVS, then 
all bets are off).

Linus has so far indicated that he likes BK, so the kernel hacking community 
will be stuck using that for awhile. However, that doesn't stop the license 
kiddies from coming out of the woodwork and mindlessly quoting the bad parts 
of the BK license (which, yes, its non-free, but at this point, who gives a 
shit). 

IMO, yes, a non-free versioning system for the crown jewel of the FLOSS 
community is a little... odd, but it was LInus's choice, and we now have to 
respect it/deal with it.

Now, I did say above (in this thread) that darcs would be really awesome for 
kernel hacking, especially since it's inherent support for multiple 
branches[1] and the ability to send changes from each other around easily 
would come in handy; however, darcs was not mature at the time of Linus's 
decision (and many say it is still not mature enough), so if Linus had 
actually chosen darcs, I (and other people here) would be now flaming him for 
choosing a versioning system that wasn't mature.

Similarly, if he had chosen arch, everyone would have flamed him for choosing 
a hard to use tool. With svn, he would have met flamage by the hands of it 
being too much like cvs and not supporting arch/darcs style branch syncing.
And if he stayed with cvs, he would have been roasted over an open fire for 
sticking with an out of date, useless, insane tool.

And if he chose anything else that I didn't previously mention, everyone would 
have donned flame retardant suits and went into the fray over the fact that 
no one has heard of that versioning system.

No matter what choice Linus would have made, he would have had some part of 
the community pissed at him, so it is ultimately his choice on what to use 
because hes the only one going to be happy with it.

[1] The Linux Kernel is looks like a forest instead of just a few branches.

(End Rant)

So, in summary, anti-BK posts on the lkml are retarded. Oh, and I apologize if 
I've put any words in your mouth, Linus.

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [darcs-users] Re: [BK] upgrade will be needed

[Sean]

On Sat, February 19, 2005 4:10 am, Patrick McFarland said:
> On Friday 18 February 2005 07:50 am, Andrea Arcangeli wrote:
>> On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
>> > RCS/SCCS format doesn't make much sence for a changeset oriented SCM.
>>
>> The advantage it will provide is that it'll be compact and a backup will
>> compress at best too. Small compressed tarballs compress very badly
>> instead, it wouldn't be even comparable. Once the thing is very compact
>> it has a better chance to fit in cache, and if it fits in cache
>> extracting diffs from each file will be very fast. Once it'll be compact
>> the cost of a changeset will be diminished allowing it to scale better
>> too.
>
> In the case of darcs, RCS/SCCS works exactly opposite of how darcs does.
> By
> using it's super magical method, it represents how code is written and how
> it
> changes (patch theory at its best). You can clearly see the direction code
> is
> going, where it came from, and how it relates to other patches.
>
> Sure, you can do this with RCS/SCCS style versioning, but whats the point?
> It
> is inefficient, and backwards.
>
>> Now it's true new disks are bigger, but they're not much faster, so if
>> the size of the repository is much larger, it'll be much slower to
>> checkout if it doesn't fit in cache. And if it's smaller it has better
>> chances of fitting in cache too.
>
> Thats all up to how the versioning system is written. Darcs developers are
> working in a checkpoint system to allow you to just grab the newest stuff,
> and automatically grab anything else you need, instead of just grabbing
> everything. In the case of the darcs linux repo, no one wants to download
> 600
> megs or so of changes.
>
>> The thing is, RCS seems a space efficient format for storing patches,
>> and it's efficient at extracting them too (plus it's textual so it's not
>> going to get lost info even if something goes wrong).
>
> It may not even be space efficient. Code ultimately is just code, and
> changes
> ultimately are changes. RCS isn't magical, and its far from it. Infact,
> the
> format darcs uses probably stores more code in less space, but don't quote
> me
> on that.
>
>> The whole linux-2.5 CVS is 500M uncompressed and 75M tar.bz2 compressed.
>
> The darcs repo which has the entire history since at least the start of
> 2.4
> (iirc anyways) to *now* is around 600 to 700.
>
>> My suggestion is to convert _all_ dozen thousand changesets to arch or
>> SVN and then compare the size with CVS (also the compressed size is
>> interesting for backups IMHO). Unfortunately I know nothing about darcs
>> yet (except it eats quite some memory ;)
>
> My suggestion is to convert _all_ dozen thousand changesets to darcs, and
> then
> compare the size with CVS. And no, darcs doesn't eat that much memory for
> the
> amount of work its doing. (And yes, they are working on that).
>
> The only thing you haven't brought up is the whole "omgwtfbbq! BK sucks,
> lets
> switch to SVN or Arch!" thing everyone else in the known universe is
> doing.
> BK isn't clearly inferior or superior to SVN or Arch or Darcs (and the
> same
> goes for SVN vs Arch vs Darcs).
>
> (Start Generic BK Thread On LKML Rant)
>
> Dear Everyone,
>
> I think if Linus is happy with BK, he should stick with it. His opinion
> ultimately trumps all of ours because he does all the hard maintainership
> work, and we don't. The only guy that gets to bitch about how much a
> versioning system sucks is the maintainer of a project (unless its CVS,
> then
> all bets are off).
>
> Linus has so far indicated that he likes BK, so the kernel hacking
> community
> will be stuck using that for awhile. However, that doesn't stop the
> license
> kiddies from coming out of the woodwork and mindlessly quoting the bad
> parts
> of the BK license (which, yes, its non-free, but at this point, who gives
> a
> shit).
>
> IMO, yes, a non-free versioning system for the crown jewel of the FLOSS
> community is a little... odd, but it was LInus's choice, and we now have
> to
> respect it/deal with it.
>
> Now, I did say above (in this thread) that darcs would be really awesome
> for
> kernel hacking, especially since it's inherent support for multiple
> branches[1] and the ability to send changes from each other around easily
> would come in handy; however, darcs was not mature at the time of Linus's
> decision (and many say it is still not mature enough), so if Linus had
> actually chosen darcs, I (and other people here) would be now flaming him
> for
> choosing a versioning system that wasn't mature.
>
> Similarly, if he had chosen arch, everyone would have flamed him for
> choosing
> a hard to use tool. With svn, he would have met flamage by the hands of it
> being too much like cvs and not supporting arch/darcs style branch
> syncing.
> And if he stayed with cvs, he would have been roasted over an open fire
> for
> sticking with an out of date, useless, insane tool.
>
> And if he chose anything else that I didn't previously mention, everyone
> would
> have donned flame retardant suits and went into the fray over the fact
> that
> no one has heard of that versioning system.
>
> No matter what choice Linus would have made, he would have had some part
> of
> the community pissed at him, so it is ultimately his choice on what to use
> because hes the only one going to be happy with it.
>
> [1] The Linux Kernel is looks like a forest instead of just a few
> branches.
>
> (End Rant)
>
> So, in summary, anti-BK posts on the lkml are retarded. Oh, and I
> apologize if I've put any words in your mouth, Linus.
>

Hey Patrick,

Good post.  One nit though is that the current thread has no anti-BK
aspect to it at all.   It's just a request that other tools be usable too
and that the BK zealotry be kept to a minimum.

Darcs sounds really interesting; will make sure to learn more about it soon.

Thanks,
Sean

Re: [darcs-users] Re: [BK] upgrade will be needed

[Andrea Arcangeli]

On Sat, Feb 19, 2005 at 04:10:18AM -0500, Patrick McFarland wrote:
> In the case of darcs, RCS/SCCS works exactly opposite of how darcs does. By 
> using it's super magical method, it represents how code is written and how it 
> changes (patch theory at its best). You can clearly see the direction code is 
> going, where it came from, and how it relates to other patches.

I don't know anything about darcs, I was only talking about arch. I
failed to compile darcs after trying for a while, so I give it up, I'll
try again eventually.

But anyway the only thing I care about is that you import all dozen
thousands changesets of the 2.5 kernel into it, and you show it's
manageable with <1G of ram and that the backup size is not very far from
the 75M of CVS.

I read in the webpage of the darcs kernel repository that they had to
add RAM serveral times to avoid running out of memory. They needed more
than 1G IIRC, and that was enough for me to lose interest into it.
You're right I blamed the functional approach and so I felt it was going
to be a mess to fix the ram utilization, but as someone else pointed
out, perhaps it's darcs to blame and not haskell. I don't know.

To me backup size matters too and for example I'm quite happy the fsfs
backend of SVN generates very small backups compared to bsddb.

> Sure, you can do this with RCS/SCCS style versioning, but whats the point? It 
> is inefficient, and backwards.

It is saved in a compact format, and I don't think it'll run slower
since if it's in cache it'll be fast and if it's I/O dominaed the more
compact it is, the faster it will be, having a compact size both for the
repository and for the backup, is more important to me.

In theory one could write a backup tool that extracts the thing and
rewrite a special backup-backend that is as space efficient as CVS and
that can compress as well as CVS, but this won't help the working copy.

> Thats all up to how the versioning system is written. Darcs developers are 
> working in a checkpoint system to allow you to just grab the newest stuff, 

This is already available with arch. Infact I suggested myself how to
improve it with hardlinks so that a checkout will take a few seconds no
matter the size of the tree.

> and automatically grab anything else you need, instead of just grabbing 
> everything. In the case of the darcs linux repo, no one wants to download 600 
> megs or so of changes.

If you use arch/darcs as a patch-download tool, then that's fine as you
say and you can already do that with arch (that in this part seems
already a lot more advanced and it's written in C btw).  Most people
just checking out the kernel with arch (or darcs) would never need to
download 600Megs of changes, but I need to download them all.

The major reason a versioning system is useful to me is to track all
changesets that touched a single file since the start of 2.5 to the
head. So I can't get away by downloading the last dozen patches and
caching the previous tree (which is perfectly doable with arch for ages
and with hardlinks as well).

> It may not even be space efficient. Code ultimately is just code, and changes 
> ultimately are changes. RCS isn't magical, and its far from it. Infact, the 

The way RCS stores the stuff compresses great. In that is "magical". I
guess SCCS is the same. fsfs isn't bad either though, and infact I'd
never use bsddb and I'd only use fsfs with SVN.

> The darcs repo which has the entire history since at least the start of 2.4 
> (iirc anyways) to *now* is around 600 to 700. 
> My suggestion is to convert _all_ dozen thousand changesets to darcs, and then 
> compare the size with CVS. And no, darcs doesn't eat that much memory for the 

What is the above 600/700 number then? I thought that was the conversion
of all dozen thousand changesets of linux-2.5 CVS to darcs.

> amount of work its doing. (And yes, they are working on that).

I'll stay tuned.

To me the only argument for not using a "magic" format like CVS or SCCS
that is space efficient and compresses efficiently, is if you claim it's
going to be a lot slower at checkouts (but infact applying some dozen
thousand patchsets to run a checkout is going to be slower than
CVS/SCCS). I know it's so much simpler to keep each patchset in a
different file like arch is already doing, but that's not the best
on-disk format IMHO.

Note that some year ago I had the opposite idea, i.e. at some point I
got convinced it was so much better to keep each patch separated from
each other like you're advocating above, until I figured out how big the
thing grows and how little space efficient it is, and how much I/O it
forces me to do, how much disk it wastes in the backup and how slow it
is as well to checkout dozen thousand patchsets.

For smaller projects without dozen thousand changesets, the patch per
file looks fine instead. For big projects IMHO being space efficient is
much more important.

Re: [darcs-users] Re: [BK] upgrade will be needed

[David Roundy]

On Sat, Feb 19, 2005 at 05:42:13PM +0100, Andrea Arcangeli wrote:
> But anyway the only thing I care about is that you import all dozen
> thousands changesets of the 2.5 kernel into it, and you show it's
> manageable with <1G of ram and that the backup size is not very far from
> the 75M of CVS.

The linux-2.5 tree right now (I'm re-doing the conversion, and am up to
October of last year, so far) is at 141M, if you don't count the pristine
cache or working directory.  That's already compressed, so you don't get
any extra bonuses.  Darcs stores with each changeset both the old and new
versions of each hunk, which gives you some redundancy, and probably
accounts for the factor of two greater size than CVS.  This gives a bit of
redundancy, which can be helpful in cases of repository corruption.

> I read in the webpage of the darcs kernel repository that they had to
> add RAM serveral times to avoid running out of memory. They needed more
> than 1G IIRC, and that was enough for me to lose interest into it.
> You're right I blamed the functional approach and so I felt it was going
> to be a mess to fix the ram utilization, but as someone else pointed
> out, perhaps it's darcs to blame and not haskell. I don't know.

Darcs' RAM use has indeed already improved somewhat... I'm not exactly sure
how much.  I'm not quite sure how to measure peak virtual memory usage, and
most of the time darcs' memory use while doing the linux kernel conversion
is under a couple of hundred megabytes.

There are indeed trickinesses involved in making sure garbage gets
collected in a timely manner when coding in a lazy language like haskell.

> On Sat, Feb 19, 2005 at 04:10:18AM -0500, Patrick McFarland wrote:
> > Thats all up to how the versioning system is written. Darcs developers
> > are working in a checkpoint system to allow you to just grab the newest
> > stuff,

Correction:  we already have a checkpoint system.  The work in progress is
making commands that examine the history fail gracefully when that history
isn't present.

> This is already available with arch. In fact I suggested myself how to
> improve it with hardlinks so that a checkout will take a few seconds no
> matter the size of the tree.

I presume you're referring to a local checkout? That is already done using
hard links by darcs--only of course the working directory has to actually
be copied over, since there are editors out there that aren't friendly to
hard-linked files.

> > and automatically grab anything else you need, instead of just grabbing
> > everything. In the case of the darcs linux repo, no one wants to
> > download 600 megs or so of changes.
> 
> If you use arch/darcs as a patch-download tool, then that's fine
...
> The major reason a versioning system is useful to me is to track all
> changesets that touched a single file since the start of 2.5 to the
> head. So I can't get away by downloading the last dozen patches and
> caching the previous tree (which is perfectly doable with arch for ages
> and with hardlinks as well).

And here's where darcs really falls down.  To track the history of a single
file it has to read the contents of every changeset since the creation of
that file, which will take forever (well, not quite... but close).

I hope to someday (when more pressing issues are dealt with) add a per-file
cache indicating which patches affect which files, which should largely
address this problem, although it won't help at all with files that are
touched by most of the changesets, and won't be optimimal in any case. :(
-- 
David Roundy
http://www.darcs.net

Re: [darcs-users] Re: [BK] upgrade will be needed

[Andrea Arcangeli]

On Sat, Feb 19, 2005 at 12:15:02PM -0500, David Roundy wrote:
> The linux-2.5 tree right now (I'm re-doing the conversion, and am up to
> October of last year, so far) is at 141M, if you don't count the pristine
> cache or working directory.  That's already compressed, so you don't get
> any extra bonuses.  Darcs stores with each changeset both the old and new
> versions of each hunk, which gives you some redundancy, and probably
> accounts for the factor of two greater size than CVS.  This gives a bit of
> redundancy, which can be helpful in cases of repository corruption.

Double size of the compressed backup is about the same as SVM with fsfs
(not tested on l-k tree but in something much smaller). Why not to
simply checksum instead of having data redundancy? Knowing when
something is corrupted is a great feature, but doing raid1 without the
user asking for it, is a worthless overhead.

The same is true for arch of course, last time I checked they were using
the default -U 3 format instead of -U 0.

> I presume you're referring to a local checkout? That is already done using
> hard links by darcs--only of course the working directory has to actually
> be copied over, since there are editors out there that aren't friendly to
> hard-linked files.

arch allows to hardlink the copy too (optionally) and it's up to you to
use the right switch in the editor (Davide had a LD_PRELOAD to do a
copy-on-write since the kernel doesn't provide the feature).

> And here's where darcs really falls down.  To track the history of a single
> file it has to read the contents of every changeset since the creation of
> that file, which will take forever (well, not quite... but close).

Indeed, and as I mentioned this is the *major* feature as far as I'm
concerned (and frankly the only one I really care about and that helps a
lot to track changes in the tree and understand why the code evolved).

Note that cvsps works great for this, it's very efficient as well (not
remotely comparable to arch at least, even if arch provided a tool
equivalent to cvsps), the only problem is that CVS is out of sync...

> I hope to someday (when more pressing issues are dealt with) add a per-file
> cache indicating which patches affect which files, which should largely
> address this problem, although it won't help at all with files that are
> touched by most of the changesets, and won't be optimimal in any case. :(

Wouldn't using the CVS format help an order of magnitude here? With
CVS/SCCS format you can extract all the patchsets that affected a single
file in a extremely efficient manner, memory utilization will be
extremely low too (like in cvsps indeed). You'll only have to lookup the
"global changeset file", and then open the few ,v files that are
affected and extract their patchsets. cvsps does this optimally
already. The only difference is that what cvsps is a "readonly" cache,
while with a real SCM it would be a global file that control all the
changesets in an atomic way.

Infact *that* global file could be a bsddb too, I don't care about how
the changset file is being encoded, all I care is that the data is a ,v
file or SCCS file so cvsps won't have to read >20000 files every time I
ask that question, which is currently unavoidable with both darcs and
arch.

Re: [darcs-users] Re: [BK] upgrade will be needed

[David Roundy]

On Sat, Feb 19, 2005 at 06:53:48PM +0100, Andrea Arcangeli wrote:
> On Sat, Feb 19, 2005 at 12:15:02PM -0500, David Roundy wrote:
> > The linux-2.5 tree right now (I'm re-doing the conversion, and am up to
> > October of last year, so far) is at 141M, if you don't count the pristine
> > cache or working directory.  That's already compressed, so you don't get
> > any extra bonuses.  Darcs stores with each changeset both the old and new
> > versions of each hunk, which gives you some redundancy, and probably
> > accounts for the factor of two greater size than CVS.  This gives a bit of
> > redundancy, which can be helpful in cases of repository corruption.
> 
> Double size of the compressed backup is about the same as SVM with fsfs
> (not tested on l-k tree but in something much smaller). Why not to
> simply checksum instead of having data redundancy? Knowing when
> something is corrupted is a great feature, but doing raid1 without the
> user asking for it, is a worthless overhead.

There are internal issues that would cause trouble here--darcs assumes that
if it knows a given patch, it also knows the patch's inverse.

> > I hope to someday (when more pressing issues are dealt with) add a per-file
> > cache indicating which patches affect which files, which should largely
> > address this problem, although it won't help at all with files that are
> > touched by most of the changesets, and won't be optimimal in any case. :(
> 
> Wouldn't using the CVS format help an order of magnitude here? With
> CVS/SCCS format you can extract all the patchsets that affected a single
> file in a extremely efficient manner, memory utilization will be
> extremely low too (like in cvsps indeed). You'll only have to lookup the
> "global changeset file", and then open the few ,v files that are
> affected and extract their patchsets. cvsps does this optimally
> already. The only difference is that what cvsps is a "readonly" cache,
> while with a real SCM it would be a global file that control all the
> changesets in an atomic way.

The catch is that then we'd have to implement a smart server to keep users
from having to download the entire history with each update.  That's not a
fundamentally hard issue, but it would definitely degrade darcs' ease of
use, besides putting additional load on the server.  So if something like
this were implemented, I think it would definitely have to be as an
optional format.

Also, we couldn't actually store the data in CVS/SCCS format, since in
darcs a patch to a single file isn't uniquely determined by two states of
that file.  But storing separately the patches relevant to different files
would definitely be an optimization worth considering.
-- 
David Roundy
http://www.darcs.net

Re: [darcs-users] Re: [BK] upgrade will be needed

[David Brown]

On Mon, Feb 21, 2005 at 07:41:54AM -0500, David Roundy wrote:

> The catch is that then we'd have to implement a smart server to keep users
> from having to download the entire history with each update.  That's not a
> fundamentally hard issue, but it would definitely degrade darcs' ease of
> use, besides putting additional load on the server.  So if something like
> this were implemented, I think it would definitely have to be as an
> optional format.
> 
> Also, we couldn't actually store the data in CVS/SCCS format, since in
> darcs a patch to a single file isn't uniquely determined by two states of
> that file.  But storing separately the patches relevant to different files
> would definitely be an optimization worth considering.

What about just a cache file that records, for each "file" which patches
affect it.  Now that I think about it, this is a little tricky, since I'm
not sure what that file would be called.  It would be easy to do for
filenames in the current version.

Dave

Re: [darcs-users] Re: [BK] upgrade will be needed

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

On Saturday 19 February 2005 12:53 pm, Andrea Arcangeli wrote:
> Wouldn't using the CVS format help an order of magnitude here? With
> CVS/SCCS format you can extract all the patchsets that affected a single
> file in a extremely efficient manner, memory utilization will be
> extremely low too (like in cvsps indeed). You'll only have to lookup the
> "global changeset file", and then open the few ,v files that are
> affected and extract their patchsets. cvsps does this optimally
> already. The only difference is that what cvsps is a "readonly" cache,
> while with a real SCM it would be a global file that control all the
> changesets in an atomic way.

But then that makes darcs do stuff the cvs way, and would make darcs exactly 
the opposite of how us darcs users want it, imho. If you're worried about 
darcs needing to open a billion files, nothing stops people from,  say, 
hacking darcs to use a SQL database to store patches in (they just have to 
code it, and I think I saw a SQL module for haskell around somewhere...)

May be I just don't understand the argument of why the CVS file format is 
anything short of insane, backwards, and outdated. We want each chunk of 
information to be both independent and have a clear history (ie, what patches 
does this patch rely on). CVS does not provide this, it is not fine grained 
enough for what darcs needs.

(David Roundy and Co can fill in the technical details of this, I'm not a 
versioning system expert)

In short, we need to move as far away from the CVS way of doing things, 
because ultimately its the wrong way. This is why I am somewhat dismayed when 
I hear of projects who move to SVN from CVS... SVN is just CVS with a few 
flaws fixed, and a few things like atomic commits added. It isn't the next 
step: it is just a small stepping stone between CVS and the next step.

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [darcs-users] Re: [BK] upgrade will be needed

[Ralph Corderoy]

Hi,

David Roundy, creator of darcs, wrote:
> On Sat, Feb 19, 2005 at 05:42:13PM +0100, Andrea Arcangeli wrote:
> > I read in the webpage of the darcs kernel repository that they had
> > to add RAM serveral times to avoid running out of memory. They
> > needed more than 1G IIRC, and that was enough for me to lose
> > interest into it.  You're right I blamed the functional approach and
> > so I felt it was going to be a mess to fix the ram utilization, but
> > as someone else pointed out, perhaps it's darcs to blame and not
> > haskell. I don't know.
> 
> Darcs' RAM use has indeed already improved somewhat... I'm not exactly
> sure how much.  I'm not quite sure how to measure peak virtual memory
> usage, and most of the time darcs' memory use while doing the linux
> kernel conversion is under a couple of hundred megabytes.

Wouldn't calling sbrk(0) help?  I don't know if the Haskell run-time
ever shrinks the data segment, if not, it could just be called at the
end.  Or a `strace -e trace=brk darcs ...' might do.  But I guess darcs
has other VM usage that doesn't show in this figure?  Does /proc/$$/maps
if running under Linux help?

A consistent way to measure would be handy for observing changes over
time.

Cheers,


Ralph.

Re: [darcs-users] Re: [BK] upgrade will be needed

[Dustin Sallings]

On Feb 18, 2005, at 1:09, Andrea Arcangeli wrote:

> darcs scares me a bit because it's in haskell, I don't believe very 
> much
> in functional languages for compute intensive stuff, ram utilization

	It doesn't sound like you've programmed in functional languages all 
that much.  While I don't have any practical experience in Haskell, I 
can say for sure that my functional code in ocaml blows my C code away 
in maintainability and performance.  Now, if I could only get it to 
dump core...

	Haskell was a draw for me.  It's very rare to find someone who 
actually knows C and can write bulletproof code in it.

> On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
>> RCS/SCCS format doesn't make much sence for a changeset oriented SCM.
>
> The advantage it will provide is that it'll be compact and a backup 
> will
> compress at best too. Small compressed tarballs compress very badly
> instead, it wouldn't be even comparable. Once the thing is very compact
> it has a better chance to fit in cache, and if it fits in cache
> extracting diffs from each file will be very fast. Once it'll be 
> compact
> the cost of a changeset will be diminished allowing it to scale better
> too.

	Then what gets transferred over the wire?  The full modified ,v file?  
Do you need a smart server to create deltas to be applied to your ,v 
files?  What do you do when someone goes in with an rcs command to 
destroy part of the history (since the storage is now mutable).

	I use both darcs and arch regularly.  darcs is a lot nicer to use from 
a human interface point of view (and the merging is really a lot 
nicer), but the nicest thing about arch is that a given commit is 
immutable.  There are no tools to modify it.  This is also why the 
crypto signature stuff was so easy to fit in.

	RCS and SCCS storage throws away most of those features.

-- 
Dustin Sallings

Re: [darcs-users] Re: [BK] upgrade will be needed

[Miles Bader]

Dustin Sallings <dustin@spy.net> writes:
> but the nicest thing about arch is that a given commit is immutable.
> There are no tools to modify it.  This is also why the crypto
> signature stuff was so easy to fit in.
>
> RCS and SCCS storage throws away most of those features.

Yeah, the basic way arch organizes its repository seems _far_ more sane
than the crazy way CVS (or BK) does, for a variety of reasons[*].  No
doubt there are certain usage patterns which stress it, but I think it
makes a lot more sense to use a layer of caching to take care of those,
rather than screwing up the underlying organization.

[*] (a) Immutability of repository files (_massively_ good idea)
    (b) Deals with tree-changes "naturally" (CVS-style ,v files are a
        complete mess for anything except file-content changes)
    (c) Directly corresponds to traditional diff 'n' patch, easy to
        think about, no surprises

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: [darcs-users] Re: [BK] upgrade will be needed

[Andrea Arcangeli]

Hello Miles,

On Mon, Feb 21, 2005 at 02:39:05PM +0900, Miles Bader wrote:
> Yeah, the basic way arch organizes its repository seems _far_ more sane
> than the crazy way CVS (or BK) does, for a variety of reasons[*].  No
> doubt there are certain usage patterns which stress it, but I think it
> makes a lot more sense to use a layer of caching to take care of those,
> rather than screwing up the underlying organization.
> 
> [*] (a) Immutability of repository files (_massively_ good idea)

what is so important about never modifying the repo? Note that only the
global changeset database and a few ,v files will be modified for each
changeset, it's not like we're going to touch all the ,v files for each
checkin. Touching the "modified" ,v files sounds a very minor overhead.

And you can incremental backup the stuff with recursive diffing the
repo too.

AFIK all other SCM except arch and darcs always modify the repo, I never
heard complains about it, as long as incremental backups are possible
and they definitely are possible.

>     (b) Deals with tree-changes "naturally" (CVS-style ,v files are a
>         complete mess for anything except file-content changes)

Certainly it's more complicated but I believe the end result will be a
better on-disk format.

Don't get me wrong, current disk format is great already for small
projects, it's the simplest approach and it's very reliable, but I don't
think the current on-disk it scales up to the l-k with reasonable
performance.

>     (c) Directly corresponds to traditional diff 'n' patch, easy to
>         think about, no surprises

Nobody is supposed to touch the repo with an editor anyway, all it
matters is how fast the command works.

And you'll be able to ask to the SCM "show me all changesets touching
this file, or even ""this range" of the file"", in the last 2 years" and
get an answer in dozen seconds like with cvsps today. even cvsps
creates an huge cache, but it doesn't need to unpack >20000 tar.gz
tarballs to create its cache. Feel free to prove me wrong and covert
current kernel CVS to arch and see how big it grows unpacked ;).

Anyway this is quickly going offtopic with l-k, so we should take it to
darcs and arch lists.

Thanks!

Re: [darcs-users] Re: [BK] upgrade will be needed

[zander]

[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]

On Mon, Feb 21, 2005 at 04:53:06PM +0100, Andrea Arcangeli wrote:
> Hello Miles,
> 
> On Mon, Feb 21, 2005 at 02:39:05PM +0900, Miles Bader wrote:
> > Yeah, the basic way arch organizes its repository seems _far_ more sane
> > than the crazy way CVS (or BK) does, for a variety of reasons[*].  No
> > doubt there are certain usage patterns which stress it, but I think it
> > makes a lot more sense to use a layer of caching to take care of those,
> > rather than screwing up the underlying organization.
> > 
> > [*] (a) Immutability of repository files (_massively_ good idea)
> 
> what is so important about never modifying the repo? Note that only the
> global changeset database and a few ,v files will be modified for each
> changeset, it's not like we're going to touch all the ,v files for each
> checkin. Touching the "modified" ,v files sounds a very minor overhead.
> 
> And you can incremental backup the stuff with recursive diffing the
> repo too.
> 
> AFIK all other SCM except arch and darcs always modify the repo, I never
> heard complains about it, as long as incremental backups are possible
> and they definitely are possible.

Well, as you seem to have never been bitten by that bug; let me assure you
the problem is very real.  Each file (,v file) can live in the repo for
many years and has to servive any spurious writes to be usable.  The
curruption of such files (in my experience) only shows itself if you try
to access its history; which may be weeks after the corruption started,
and you can't use a backup for that since you will overwrite new versions
added since.

Think about it this way;  nfs servers are known to corrupt things;
reboots can corrupt files, different clients will try to write to
the file at the same time quite often during the lifetime of the file, cvs
clients get killed during writes or network drops the connection during a
session.
Considering that the ,v files have a lifetime of years, with many
modifications during that time, I think its amazing corruption does not
happen more often.

CVS was pretty good at keeping files sane, but I'll go for a solution that
completely sidesteps said problem any day.

-- 
Thomas Zander

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [darcs-users] Re: [BK] upgrade will be needed

[Horst von Brand]

zander@kde.org said:
> On Mon, Feb 21, 2005 at 04:53:06PM +0100, Andrea Arcangeli wrote:

[...]

> > AFIK all other SCM except arch and darcs always modify the repo, I never
> > heard complains about it, as long as incremental backups are possible
> > and they definitely are possible.

> Well, as you seem to have never been bitten by that bug; let me assure you
> the problem is very real.  Each file (,v file) can live in the repo for
> many years and has to servive any spurious writes to be usable.  The
> curruption of such files (in my experience) only shows itself if you try
> to access its history; which may be weeks after the corruption started,
> and you can't use a backup for that since you will overwrite new versions
> added since.

Marking files read-only won't save you from corruption by NFS or the disk
or the kernel or... randomly scribbling around.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [darcs-users] Re: [BK] upgrade will be needed

[Andreas Gruenbacher]

On Mon, 2005-02-21 at 20:45, zander@kde.org wrote:
> CVS was pretty good at keeping files sane, but I'll go for a solution that
> completely sidesteps said problem any day.

One way to get the benefits of both worlds would be to keep an
additional history of changes (in whatever form) that allows to rebuild
the ,v files.

RE: [BK] upgrade will be needed

[Martin Fouts]

In the United States, Ford isn't legally allowed to do that.  What you
are asking for in your license, it seems to me, is what is already
provided for in the DMCA: you wish that users not reverse engineer your
product.  You do not need a license clause for this, as the DMCA already
covers it; and if you did, the clause would read 'thou shalt not reverse
engineer this product or allow your copy to be used to reverse engineer
this product' rather than 'thou shalt not compete with this product.'

A clause requiring that a user not compete is probably going to look
like an attempt at restraint of trade to a judge, and even for
employees, the limits you can put on their re-employability are
restricted by anti-monopoly law.


-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Larry McVoy
Sent: Monday, February 14, 2005 8:00 AM
To: Steven Rostedt
Cc: Mws; LKML
Subject: Re: [BK] upgrade will be needed

On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote:
> Can you see Ford Motors telling
> someone that you can't go work for GM if you drive a Ford?

You paid for the Ford.  Suppose Ford offered to give you the car but
said if you take it then you can't go work at GM because this car is
ahead of their technology.

See the difference?  It's one thing if you plunked your money down and
took the standard license or a negotiated license.  You are getting an
expensive product and not paying any money for it.  The payment is the
terms you agree to in the license and the obligations of those terms.
That payment may be unacceptable to you, which is your choice.
--
---
Larry McVoy                lm at bitmover.com
http://www.bitkeeper.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in the body of a message to majordomo@vger.kernel.org More majordomo
info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [BK] upgrade will be needed

[Martin Fouts]

 
I don't believe a non-compete clause accomplishes your goal, as I've
recently written.  On the other hand, a "don't reverse engineer and
don't allow your copy to be used to reverse engineer" clause does.

The "no reverse" clause is pretty common and difficult to argue against.
The non-compete clause is probably not enforcable and looks like
restraint of trade.

Marty
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Larry McVoy
Sent: Monday, February 14, 2005 10:56 AM
To: Matthew Jacob
Cc: Jeff Sipek; Bartlomiej Zolnierkiewicz; linux-kernel@vger.kernel.org
Subject: Re: [BK] upgrade will be needed


If anyone can think of a better way for us to both let you use the tool
and protect our hard work, I'm listening.  The repeated outrage over the
restrictions isn't any more fun for me than it is for you.  Any answer,
however, has to take our issues into consideration as well as yours.