Bitkeeper

Bitkeeper

[Richard Stallman]

    > If you are trying to copy BK, give it up.  We'll simply follow in the
    > footsteps of every other company faced with this sort of thing and change
    > the protocol every 6 months.  Since you would be chasing us you can never
    > catch up.  If you managed to stay close then we'd put digital signatures
    > into the protocol to prevent your clone from interoperating with BK.

I think it would be appropriate at this point to write a free client
that talks with Bitkeeper, and for Linux developers to start switching
to that from Bitkeeper.  At that point, McVoy will face a hard choice:
if he carries out these threats, he risks alienating the community
that he hopes will market Bitkeeper for him.

Re: Bitkeeper

[Rik van Riel]

On Fri, 18 Jul 2003, Richard Stallman wrote:

> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper,

Maybe.  I'll leave that decision to whomever decides to
invest his time and/or money in implementing such software.

> and for Linux developers to start switching to that from Bitkeeper.

That would be a bit premature.  I certainly wouldn't switch
to a piece of software that doesn't exist yet. ;)

To put it more bluntly: free software would have to implement
a very significant amount of Bitkeeper's functionality before
I would ever consider switching to it.

At the moment there simply is no equivalent free alternative
to Bitkeeper, so there's nothing to switch to.  Once such an
alternative exists we could continue this debate.

kind regards,

Rik
-- 
Great minds drink alike.

Re: Bitkeeper

[nick]

How about all of you take a much nicer tilt on this, and ask McVoy (who's
already giveing you the software free) his price to GPL bitkeeper.
	Nick

On Fri, 18 Jul 2003, Rik van Riel wrote:

> On Fri, 18 Jul 2003, Richard Stallman wrote:
> 
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper,
> 
> Maybe.  I'll leave that decision to whomever decides to
> invest his time and/or money in implementing such software.
> 
> > and for Linux developers to start switching to that from Bitkeeper.
> 
> That would be a bit premature.  I certainly wouldn't switch
> to a piece of software that doesn't exist yet. ;)
> 
> To put it more bluntly: free software would have to implement
> a very significant amount of Bitkeeper's functionality before
> I would ever consider switching to it.
> 
> At the moment there simply is no equivalent free alternative
> to Bitkeeper, so there's nothing to switch to.  Once such an
> alternative exists we could continue this debate.
> 
> kind regards,
> 
> Rik
> -- 
> Great minds drink alike.
> 
> -
> 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: Bitkeeper

[Shawn]

Wow, I've just totally underestimated the $$ power on this list. ;)

On Fri, 2003-07-18 at 15:22, nick@snowman.net wrote:
> How about all of you take a much nicer tilt on this, and ask McVoy (who's
> already giveing you the software free) his price to GPL bitkeeper.

Re: Bitkeeper

[Alan Cox]

On Gwe, 2003-07-18 at 21:22, nick@snowman.net wrote:
> How about all of you take a much nicer tilt on this, and ask McVoy (who's
> already giveing you the software free) his price to GPL bitkeeper.

Make Larry a clear business case and I'm sure he will. However even
though I don't agree with Larry on a lot of things I do agree that there
isn't a sane case for him to GPL that software.

Larry actually had exactly these and related discussions before he ever
went to Linus and others with the arrangement he proposed about free if
your logs are public.

If you want to make something replace bitkeeper make it better. When
Larry has customers forcing him to write bk to [whatever] convertors
you've won. 

Re: Bitkeeper

[Pavel Machek]

Hi!

> > How about all of you take a much nicer tilt on this, and ask McVoy (who's
> > already giveing you the software free) his price to GPL bitkeeper.
> 
> Make Larry a clear business case and I'm sure he will. However even
> though I don't agree with Larry on a lot of things I do agree that there
> isn't a sane case for him to GPL that software.
> 
> Larry actually had exactly these and related discussions before he ever
> went to Linus and others with the arrangement he proposed about free if
> your logs are public.
> 
> If you want to make something replace bitkeeper make it better. When
> Larry has customers forcing him to write bk to [whatever] convertors
> you've won. 

Well, we already made him write bk to CVS convertor ;-))))))))).

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Bitkeeper

[Jeff Garzik]

THIS IS NOT A BITKEEPER MAILING LIST.

Thanks,

	Jeff

Re: Bitkeeper

[Shawn]

To add to this, why?

I don't mean to jump on anyone, but so long as someone can pull all the
BK data out if Larry gets unreasonable (via the active and existing SVN
or CVS gateways) who the frig cares if there's a BK clone??? If things
got nasty, pull the data and switch unceremoniously switch to SVN or
whatever.

Are there folks out there today with current SVN repos which have all
the BK metadata everyone keeps pissing on about?

On Fri, 2003-07-18 at 15:06, Rik van Riel wrote:
> On Fri, 18 Jul 2003, Richard Stallman wrote:
> 
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper,
> 
> Maybe.  I'll leave that decision to whomever decides to
> invest his time and/or money in implementing such software.
> 
> > and for Linux developers to start switching to that from Bitkeeper.
> 
> That would be a bit premature.  I certainly wouldn't switch
> to a piece of software that doesn't exist yet. ;)

Re: Bitkeeper

[Rik van Riel]

On 18 Jul 2003, Shawn wrote:

> To add to this, why?

That's a good question indeed.

> I don't mean to jump on anyone, but so long as someone can pull all the
> BK data out

You're right.  There is no data lock-in, so there is no reason
at all why we (FSVO "we") would even need a free alternative to
Bitkeeper.

People who really care about Bitkeeper being non-free can work
towards making a free alternative. Some people are doing exactly
that (I bet you won't see them in this thread though, they're
too busy doing useful stuff).

Re: Bitkeeper

[Jan-Benedict Glaw]

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

On Fri, 2003-07-18 15:32:06 -0500, Shawn <core@enodev.com>
wrote in message <1058560325.2662.31.camel@localhost>:
> To add to this, why?
> 
> I don't mean to jump on anyone, but so long as someone can pull all the
> BK data out if Larry gets unreasonable (via the active and existing SVN
> or CVS gateways) who the frig cares if there's a BK clone??? If things
> got nasty, pull the data and switch unceremoniously switch to SVN or
> whatever.

Have you ever used eg. cvsps with the BK->CVS gateway? I tried this and
failed because of 4 issues:

	- I couldn't get the initial import patchset (2)
	- I couldn't get two other patchsets
	- One patchset added a file which already existed (11504)

Trying cvsps with the BKCVS gateway, you won't be able to automagically
import all these patchsets into some other SCM. I got the BKCVS->SVN
script and I'm still looking at it. Other than that, I'm to have a deep
look at cvsps if there's some hidden bug which lets it fail on mentioned
four patchsets...

However, I want to thank Larry for the BC->CVS gateway. Eventually, some
customers could make some use out of it, but it definitively tells us
that Larry is willing to do more than giving BK away (in most cases for
free (as in beer)) - he's investing in it as well as tryin' to keep us
using it (for what he offers some small presents from time to time such
as hosting service and BK->CVS).

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

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

Re: Bitkeeper

[Larry McVoy]

On Sat, Jul 19, 2003 at 08:42:46PM +0200, Jan-Benedict Glaw wrote:
> Have you ever used eg. cvsps with the BK->CVS gateway? I tried this and
> failed because of 4 issues:
> 
> 	- I couldn't get the initial import patchset (2)
> 	- I couldn't get two other patchsets
> 	- One patchset added a file which already existed (11504)

Work with Ben Collins on that.  I don't know what cvsps is so I can't
help you there.  If you can figure out what is wrong with the tree and 
explain what we should do to fix it, we'll give it a tree.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Jan-Benedict Glaw]

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

On Sat, 2003-07-19 11:49:44 -0700, Larry McVoy <lm@bitmover.com>
wrote in message <20030719184944.GC24197@work.bitmover.com>:
> On Sat, Jul 19, 2003 at 08:42:46PM +0200, Jan-Benedict Glaw wrote:
> > Have you ever used eg. cvsps with the BK->CVS gateway? I tried this and
> > failed because of 4 issues:
> > 
> > 	- I couldn't get the initial import patchset (2)
> > 	- I couldn't get two other patchsets
> > 	- One patchset added a file which already existed (11504)
> 
> Work with Ben Collins on that.  I don't know what cvsps is so I can't
> help you there.  If you can figure out what is wrong with the tree and 
> explain what we should do to fix it, we'll give it a tree.

Thanks fot hint'n'offer!

Basically, cvsps sucks off the rlog messages and compares any check-in
texts / times of any files to find out what has been checked-in with a
single check-in. That is then called a patchset (cvs_ps_). With some
command line arguments, it'll then output the check-in text as well as a
unified diff.

This information can then be used to feed it to other SCMs or for simple
review tasks. While doing consistency checks, I discivered the mentioned
inconsistency (at patchset 11504 IIRC) as well as some minor glitches (I
had one patchset where the check-in comment changed after I re-fetched
the patchset some days later...).

However, I'm working at spare time on it, so it'll take some time:(

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

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

Re: Bitkeeper

[Larry McVoy]

> Basically, cvsps sucks off the rlog messages and compares any check-in

Hmm.  I would guess that makes rlog very happy.  And sleepy :)

> texts / times of any files to find out what has been checked-in with a
> single check-in. That is then called a patchset (cvs_ps_). With some
> command line arguments, it'll then output the check-in text as well as a
> unified diff.

We're looking at getting some seperate bandwidth for bkbits.net and 
turning on the patch feature of BK/Web.  Then you'll be able to do a

    wget http://linux.bkbits.net/linux-2.5/gnupatch@1.5234

and get something like the following.  I suspect this is better than
cvsps and it will work for all repositories on bkbits.net, not just 
the mainline one.  Is that good enough for what you want?  The format
below repeats for each file in the changeset.

===== man/man1/bk-config-etc.1 1.23.1.1 vs 1.26 =====
02/05/16 13:44:09 wscott@wscott1.homeip.net 1.24 +16 -0
   Document 'trust_window' parameter
02/10/03 11:24:15 wscott@desk.wscott1.homeip.net 1.23.1.2 +9 -0
   Docuement the BK_CONFIG environmental variable

--- 1.23.1.1/man/man1/bk-config-etc.1   Tue Sep 17 12:33:59 2002
+++ 1.26/man/man1/bk-config-etc.1       Thu Oct  3 09:24:49 2002
@@ -30,6 +30,15 @@
 (/etc/BitKeeper/etc/config) then that setting will override any 
 matching key in local config files.  
 .LP
+Also configuration entries can be overridden with the
+.B BK_CONFIG
+environmental variable.  That variable can contain a list of key:value
+pairs seperated by semicolons.  For example:
+.DS
+.BR BK_CONFIG =\c
+.IR key1 : value2 ; key2 : value2 ; key3 : value3\c
+.DE
+.LP
 Minimum content requirements for the BitKeeper/etc/config file 

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

Re: Bitkeeper

[Jan-Benedict Glaw]

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

On Sat, 2003-07-19 12:05:31 -0700, Larry McVoy <lm@bitmover.com>
wrote in message <20030719190531.GB24698@work.bitmover.com>:
> > Basically, cvsps sucks off the rlog messages and compares any check-in
> 
> Hmm.  I would guess that makes rlog very happy.  And sleepy :)

Well, it's not exactly fast and it takes quite some CPU cycles on my
side. However, that's a spare box (HP-PARISC B132L+, 132 MHz) which
doesn't have to do anything else:)

> 
>     wget http://linux.bkbits.net/linux-2.5/gnupatch@1.5234
> 
> and get something like the following.  I suspect this is better than
> cvsps and it will work for all repositories on bkbits.net, not just 
> the mainline one.  Is that good enough for what you want?  The format
> below repeats for each file in the changeset.

That's quite good:) Are file renames also represented as patches (ie.
one file gets removed, another one is added)?

To draw the line, that's exactly what one could wish. It someone isn't
happy with the format, it seems to be easily Perl'ed/sed'ed/...

I've not yet looked at any other trees than the linux-2.5^H6 tree, but
I'm currently spending some time to work on merging some trees to one
(read: I want to merge all the non-i386 linux ports) and that involves
quite some scripting / SCMing and up to now, I've not found the
Super-SCM to achieve that:) Tasks are to get all ports to current 2.6.x,
distribute their patches among them and pushing it (separated in small
pieces) to Linus at some far future...

If I could get perfect patches like that out of bkbits.net (at least for
the projects hosted there), that could potentially ease the task a lot:)

MfG, JBG
PS: http://lug-owl.de/~jbglaw/linux-ports/
PPS: I'm missing quite a lot of informations there - if you're a port
maintainer, please get in contact with me:)

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

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

Re: Bitkeeper

[Trever L. Adams]

On Fri, 2003-07-18 at 15:51, Richard Stallman wrote:
>     > If you are trying to copy BK, give it up.  We'll simply follow in the
>     > footsteps of every other company faced with this sort of thing and change
>     > the protocol every 6 months.  Since you would be chasing us you can never
>     > catch up.  If you managed to stay close then we'd put digital signatures
>     > into the protocol to prevent your clone from interoperating with BK.
> 
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.

I can't believe I am going to do this.  Especially, where most of my
contributions to OSS/Free Software are not known on this list and the
argument is stupid.

McVoy, changing the protocol would be extremely stupid.  However, it is
your product, so do as you wish.

Stallman, believe it or not, you used to be someone I looked up to a
great deal.  I still think some of your ideas are great and I would love
to see the entire world as open source.  However, to encourage people to
do things that are known to antagonize others is crazy.  CVS is crap.  I
haven't used Bitkeeper but I have tried a lot of others, and they are
junk.  So, if Bitkeeper is as good as Linus et al think it is, then it
would be insane to do anything to ruin the relationship they have with
Bitkeeper.  Ideology is great, but it does have to be tempered and meted
out so that it can be implemented in a way that brings the most good to
everyone.  At this point, ticking off McVoy will likely do the opposite.

McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
I have said before, I hope there is some way your software can become
more open, but I will leave that up to you and your team to figure out
when and how.

Have a good one everyone.

Trever
--
"All this technology has somehow made you a stranger in your own land."
-- Robert M. Pirsig

Re: Bitkeeper

[Shawn]

I second that "Ata boy!". Larry, thank you, for all the help you gave
Linus in the switch over, all the LK specific tweaks to BK, etc.

On Fri, 2003-07-18 at 15:09, Trever L. Adams wrote:
> McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
> I have said before, I hope there is some way your software can become
> more open, but I will leave that up to you and your team to figure out
> when and how.

Re: Bitkeeper

[Larry McVoy]

> McVoy, changing the protocol would be extremely stupid.  

There are problems with the current protocol which can't be fixed without
a protocol rev, problems that many of the kernel developers have asked us
to fix.  Sooner or later we are going to fix them and then there will be
a protocol rev.  It's possible we might do one for legal reasons but I
doubt it.  I was just pointing out to Rory that if he insisted on doing
something in direct violation of our license it wouldn't do him any good
in the long run.

> McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As

My pleasure.  At least that part of all of this has worked out pretty
well.  We still think BK is nowhere near good enough, there is a lot left
to be done.  I just spent the day with one of the MySQL founders talking
about tools for doing reviews, I think those could help.  It might be very
cool, for example, if there was a way to distribute the review process
and have everyone looking over code, recording notes about possible
problems, etc.  Then Dave could grab an espresso, hit the web site,
look over the code he cares about, see the reviews, fix it, move on.
It's sort of "attach the bug report directly to the code" rather than
have a bug report.  Don't know if it will work or not but we may try it.
Stuff like that is potentially useful and part of the reason we think
we're nowhere near done.  
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Trever L. Adams]

On Fri, 2003-07-18 at 17:03, Larry McVoy wrote:
> > McVoy, changing the protocol would be extremely stupid.  
> 
> There are problems with the current protocol which can't be fixed without
> a protocol rev, problems that many of the kernel developers have asked us
> to fix.  Sooner or later we are going to fix them and then there will be
> a protocol rev.  It's possible we might do one for legal reasons but I
> doubt it.  I was just pointing out to Rory that if he insisted on doing
> something in direct violation of our license it wouldn't do him any good
> in the long run.
> 

Ah, sorry.  I was meaning the Microsoft kind of switching is stupid. 
You have tech reasons, great do them.  Mr. McVoy, sorry about my blanket
statement.  You obviously weren't just acting the way I thought you
were.

> > McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
> 
> My pleasure.  At least that part of all of this has worked out pretty
> well.  We still think BK is nowhere near good enough, there is a lot left
> to be done.  I just spent the day with one of the MySQL founders talking
> about tools for doing reviews, I think those could help.  It might be very
> cool, for example, if there was a way to distribute the review process
> and have everyone looking over code, recording notes about possible
> problems, etc.  Then Dave could grab an espresso, hit the web site,
> look over the code he cares about, see the reviews, fix it, move on.
> It's sort of "attach the bug report directly to the code" rather than
> have a bug report.  Don't know if it will work or not but we may try it.
> Stuff like that is potentially useful and part of the reason we think
> we're nowhere near done.  

Now that is a fantastic idea, kind of like cvs meets bugzilla in one
product.  I hope you are able to do it.

Anyway, please, everyone either take it private with me, or leave me out
of it.  At this point everyone knows how I feel about the issue and why
I do.  All of these arguments only seem to reinforce those feelings and
thoughts.

RMS thank you for the good you do.  Linus and all, thank you VERY much
for all the good you do.  Larry, thank you for your kind response.

Good day to you all.

Trever
--
"In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away." --
RFC1925: The Twelve Networking Truths

Re: Bitkeeper

[Mike Fedyk]

On Fri, Jul 18, 2003 at 04:09:42PM -0400, Trever L. Adams wrote:
> McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As

One nit.

I don't think Alan is using BK.  I could be wrong though.

Re: Bitkeeper

[Alan Cox]

On Gwe, 2003-07-18 at 23:17, Mike Fedyk wrote:
> On Fri, Jul 18, 2003 at 04:09:42PM -0400, Trever L. Adams wrote:
> > McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
> 
> One nit.
> 
> I don't think Alan is using BK.  I could be wrong though.

I'm not - and with the snapshots neither I or anyone else is forced to.

Re: Bitkeeper

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Gwe, 2003-07-18 at 23:17, Mike Fedyk wrote:
> > On Fri, Jul 18, 2003 at 04:09:42PM -0400, Trever L. Adams wrote:
> > > McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
> > 
> > One nit.
> > 
> > I don't think Alan is using BK.  I could be wrong though.
> 
> I'm not - and with the snapshots neither I or anyone else is forced to.

For the linux kernel.  The problem is the satellite projects which
adopt bitkeeper less carefully.  Unless there is a general gateway I
have missed.

Eric

Re: Bitkeeper

[Mark Mielke]

On Sat, Jul 19, 2003 at 02:20:31AM -0600, Eric W. Biederman wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > > I don't think Alan is using BK.  I could be wrong though.
> > I'm not - and with the snapshots neither I or anyone else is forced to.
> For the linux kernel.  The problem is the satellite projects which
> adopt bitkeeper less carefully.  Unless there is a general gateway I
> have missed.

They do not provide snapshots?

As long as tar files are distributed for each minor release, there is no
true 'lock in'. If you need a gateway for a specific satellite project,
there are people that could probably hook you up with the software required,
and if there are other people in your situation, one of them probably has
enough CPU + network + disk resources to host it.

The Bit Keeper issue is entirely a philosophical one. I understand
that Linus chooses to use it, because it allows him to be more
efficient. Alan Cox chooses not to use it (I'm not clear on his
reasons, but I assume they are just as good). What more proof do we
need that Bit Keeper is not locking people in?

I don't use it, and have never used it at this point, primarily
because I happen to be in the source management field currently, and I
have chosen to respect Larry's license. I'm certain that if I ever had
a proper need in terms of kernel development, the license could be
waived or altered on a case-by-case basis.

Stallman puts himself 100% in the philosopher's chair. He seems to believe
that any variation or compromise weakens his overall position. Every few
months he starts a flame war just to satisfy his own guilt that rises from
him feeling that he isn't doing enough to 'promote' free projects, even if
the free projects don't exist yet, or are not as feature-full.

A few of us have a real love-hate relationship with Stallman. We love what he
has accomplished. We hate how he accomplishes his goals.

The bottom line of all of this, is that Stallman is preaching to the wrong
people. He should stick to press releases and such. Kernel developers just
want to get work done. Any investment into writing a new source management
system would be better served by improving the linux source code. If this
wasn't so, the kernel developers wouldn't be kernel developers. They would
be like me... source management developers... :-)

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: Bitkeeper

[Scott Robert Ladd]

Trever L. Adams wrote
> Stallman, believe it or not, you used to be someone I looked up to a
> great deal.  I still think some of your ideas are great and I would love
> to see the entire world as open source.  However, to encourage people to
> do things that are known to antagonize others is crazy.  CVS is crap.  I
> haven't used Bitkeeper but I have tried a lot of others, and they are
> junk.  So, if Bitkeeper is as good as Linus et al think it is, then it
> would be insane to do anything to ruin the relationship they have with
> Bitkeeper.  Ideology is great, but it does have to be tempered and meted
> out so that it can be implemented in a way that brings the most good to
> everyone.  At this point, ticking off McVoy will likely do the opposite.
> 
> McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
> I have said before, I hope there is some way your software can become
> more open, but I will leave that up to you and your team to figure out
> when and how.

You are being far too rational for this discussion.

While I may have my disagreements with Larry at times, I appreciate his 
patience in granting BitKeeper to the kernel developers.

RMS is a political idealist -- a good thing, in that such people help 
bring about shifts in society. But like all idealists, he's become 
trapped his dogma, fixated on finding battles to fight, even in other 
people's realms.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: Bitkeeper

[Michael Buesch]

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

On Friday 18 July 2003 21:51, Richard Stallman wrote:
>     > If you are trying to copy BK, give it up.  We'll simply follow in the
>     > footsteps of every other company faced with this sort of thing and
>     > change the protocol every 6 months.  Since you would be chasing us
>     > you can never catch up.  If you managed to stay close then we'd put
>     > digital signatures into the protocol to prevent your clone from
>     > interoperating with BK.
>
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.

Hi Richard.

You're ready for a small flame-war with Larry? 8-)

First I think, this list isn't the correct place for starting
a bk-flame again.
But I also share your opinion, that it's time to write even a
free client.
But how hard will it be? How big is the knowlege of the
protocols bk uses? It'll be not easy, but for sure very interesting.

- -- 
Regards Michael Buesch
http://www.8ung.at/tuxsoft
Penguin on this machine:  Linux 2.4.21  - i386

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/GFjZoxoigfggmSgRAs7XAJ4tZybSXfPTdk7I9cSIuUYSM72xXACfaeOZ
k2QsR3KsL6HxXXj1y/ECdn0=
=2Wzr
-----END PGP SIGNATURE-----

Re: Bitkeeper

[Shawn]

In my mind it's absolutely not worth it. I believe there are
non-commercial protocol gateways from which a copy of linux (complete
with historical BK metadata) can be pulled and converted from.

Larry has his views whether 99.9999% of people disagree with him or not.
He can change the protocol as he sees fit, and we can pull the source
off of BK if we want.

He has stated before, it would be no skin off his balls (to paraphrase).

On Fri, 2003-07-18 at 15:30, Michael Buesch wrote:
> First I think, this list isn't the correct place for starting
> a bk-flame again.
> But I also share your opinion, that it's time to write even a
> free client.
> But how hard will it be? How big is the knowlege of the
> protocols bk uses? It'll be not easy, but for sure very interesting.

Re: Bitkeeper

[Larry McVoy]

I'm trying hard to stay out of this, I think Richard may be trolling,
but I need to make sure that people understand that what Richard is 
suggesting is violation of our license and copyright.

On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.

Our license states that you can't use BK if you are developing a similar
system, i.e., a clone.  Without using BK it's impossible to reverse
engineer BK to create the clone.  So your message seems to be saying
"it would be appropriate at this point to violate the BitKeeper license
in order to write a free client which talks with BitKeeper".

Are you really instructing people to go out and violate our license?  
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Shawn]

Again, to add to that, the very existence of BK2SVN and BK2CVS would
seem support the assertion that the license/copyright allow
"work-(sort-of)-alike" developers like (SVN guys) to use the protocol
gateways. It only prevents them from using BK itself.

Really, the existence of the gateways was the end-all answer to the
arguments folks had. The only thing really left is that the gateways
operate on the charity of Larry.

So, just keep those repos up to date from the gateways, and if they stop
working one day, then bitch. But understand, Larry is well within his
rights in all his assertions; he's just quite a bit right of hard line
GNU.

On Fri, 2003-07-18 at 15:44, Larry McVoy wrote:
> I'm trying hard to stay out of this, I think Richard may be trolling,
> but I need to make sure that people understand that what Richard is 
> suggesting is violation of our license and copyright.
> 
> On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper, and for Linux developers to start switching
> > to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> > if he carries out these threats, he risks alienating the community
> > that he hopes will market Bitkeeper for him.
> 
> Our license states that you can't use BK if you are developing a similar
> system, i.e., a clone.  Without using BK it's impossible to reverse
> engineer BK to create the clone.  So your message seems to be saying
> "it would be appropriate at this point to violate the BitKeeper license
> in order to write a free client which talks with BitKeeper".
> 
> Are you really instructing people to go out and violate our license?  

RE: Bitkeeper

[David Schwartz]

> Our license states that you can't use BK if you are developing a similar
> system, i.e., a clone.  Without using BK it's impossible to reverse
> engineer BK to create the clone.  So your message seems to be saying
> "it would be appropriate at this point to violate the BitKeeper license
> in order to write a free client which talks with BitKeeper".

> Larry McVoy              lm at bitmover.com

	My understanding of the relevant case law in the United States is that
these types of restrictions are not allowed under copyright law itself.
They've only been upheld when they're part of a sale contract. You can
certainly argue that a click to an 'I Agree' link constitutes acceptance of
a sale contract. But if someone sits down at a friend's computer that
happens to have BK on it, or finds a copy of BK on a CD someone left at the
lab, you would have a hard time arguing that they agreed to this contract.

	See, for example, ProCD v. Zeidenberg:

"Copyright law forbids duplication, public performance, and so on, unless
the person wishing to copy or perform the work gets permission; silence
means a ban on copying. A copyright is a right against the world. Contracts,
by contrast, generally affect only their parties; strangers may do as they
please, so contracts do not create "exclusive rights." Someone who found a
copy of SelectPhone(TM) on the street would not be affected by the
shrinkwrap license - though the federal copyright laws of their own force
would limit the finder's ability to copy or transmit the application
program."

	IANAL, and in any event, I don't think any court would look fondly on
someone who deliberately contrived a method to claim they're not subject to
the license.

	DS

RE: Bitkeeper

[Shawn]

Maybe you're right, but to the point of the conversation, 'taint worth
it to fight it.

The worst thing anyone can do is go off half cocked, make a challenge,
and *poof*, the protocol gateways disappear, because now Larry is
spending his time & $$ with the lawsuit, and takes down the protocol
gateways.

So, in essence, I say pick the battles that are worth fighting, and then
only the battles that are worth winning.

On Fri, 2003-07-18 at 16:08, David Schwartz wrote:
> > Our license states that you can't use BK if you are developing a similar
> > system, i.e., a clone.  Without using BK it's impossible to reverse
> > engineer BK to create the clone.  So your message seems to be saying
> > "it would be appropriate at this point to violate the BitKeeper license
> > in order to write a free client which talks with BitKeeper".
> 
> > Larry McVoy              lm at bitmover.com
> 
> 	My understanding of the relevant case law in the United States is that
> these types of restrictions are not allowed under copyright law itself.
> They've only been upheld when they're part of a sale contract. You can
> certainly argue that a click to an 'I Agree' link constitutes acceptance of
> a sale contract. But if someone sits down at a friend's computer that
> happens to have BK on it, or finds a copy of BK on a CD someone left at the
> lab, you would have a hard time arguing that they agreed to this contract.
> 
> 	See, for example, ProCD v. Zeidenberg:
> 
> "Copyright law forbids duplication, public performance, and so on, unless
> the person wishing to copy or perform the work gets permission; silence
> means a ban on copying. A copyright is a right against the world. Contracts,
> by contrast, generally affect only their parties; strangers may do as they
> please, so contracts do not create "exclusive rights." Someone who found a
> copy of SelectPhone(TM) on the street would not be affected by the
> shrinkwrap license - though the federal copyright laws of their own force
> would limit the finder's ability to copy or transmit the application
> program."
> 
> 	IANAL, and in any event, I don't think any court would look fondly on
> someone who deliberately contrived a method to claim they're not subject to
> the license.
> 
> 	DS

Re: Bitkeeper

[Alan Cox]

On Gwe, 2003-07-18 at 21:44, Larry McVoy wrote:
> I'm trying hard to stay out of this, I think Richard may be trolling,
> but I need to make sure that people understand that what Richard is 
> suggesting is violation of our license and copyright.

Actually your license is simply irrelevant in most of thre world. You
aren't allowed to forbid reverse engineering for interoperability.

Re: Bitkeeper

[David Lang]

actually I think that your case for ignoring the 'no reverse engineering'
would be far better if you paid for a bitkeeper license, but when you are
being allowed to use it for free on the condition that you use it specific
ways (no reverse engineering and public access to changeset info) saying
that you will eliminate complying with those terms but still get to use it
for free isn't being very reasonable.

David Lang

 On 18 Jul 2003, Alan Cox wrote:

> Date: 18 Jul 2003 22:23:30 +0100
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: Larry McVoy <lm@bitmover.com>
> Cc: Richard Stallman <rms@gnu.org>,
>      Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: Bitkeeper
>
> On Gwe, 2003-07-18 at 21:44, Larry McVoy wrote:
> > I'm trying hard to stay out of this, I think Richard may be trolling,
> > but I need to make sure that people understand that what Richard is
> > suggesting is violation of our license and copyright.
>
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.
>
> -
> 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: Bitkeeper

[Valdis.Kletnieks]

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

On Fri, 18 Jul 2003 22:23:30 BST, Alan Cox said:

> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.

http://marc.theaimsgroup.com/?l=linux-kernel&m=100374609914587&w=2

2.2.20pre11
o	Security fixes
	| Details censored in accordance with the US DMCA

And there's the resignation letter from ALS from a certain LKML regular, too....

Now what's this about the "simply irrelevant"?  Now admittedly the DMCA issues
were on the criminal side of the legal system rather than the civil side, but
the same "You land at the airport and have a chat with the sheriff's deputy"
issue still applies - it's merely a lawsuit rather than an arrest warrant...


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

Re: Bitkeeper

[Alan Cox]

On Gwe, 2003-07-18 at 22:54, Valdis.Kletnieks@vt.edu wrote:
> Now what's this about the "simply irrelevant"? 

"in most of the world"

If everyone spent the time replacing bitkeeper instead of beating up
Larry they'd get a lot further. I appreciate beating up Larry is more
fun but....

Re: Bitkeeper

[Trever L. Adams]

On Fri, 2003-07-18 at 17:23, Alan Cox wrote:
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.

Well, here in the US the right to reverse engineer may be gone.  It lost
out in a recent case.  Hopefully that isn't telling of the future and
future court cases.

Long live that right everywhere, even if the US sticks its legal head up
a dark, dark tunnel.

Trever
--
"Love is friendship set on fire." -- French Proverb

Re: Bitkeeper

[Larry McVoy]

On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> 	My understanding of the relevant case law in the United States is that
> these types of restrictions are not allowed under copyright law itself.

On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.

    "Judge, I want to violate this license on this product that I got
    for free because it's not free enough".

    "Judge, we give it out for free and we also developed technology
    to transfer the data out of our product and into a GPLed product,
    we do that at our expense and even host the competing GPLed repos
    for free and they still want to violate the license"

Who do you think is going to win that one?

Besides, have you considered that it is that license you appear to
dislike so much which provides for the product, the hosting, the free
public machines, the support, all of that?  It's a pile of money and
time and I don't see RMS steppng forward with an open checkbook.

The license means we have a revenue stream.  We use a significant portion
of that revenue stream to help Linux.  If the revenue stream goes away
then so do the services we provide to you for free.  They obviously
have value or you wouldn't be using them.  
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Marcus Metzler]

Larry McVoy writes:
 > Who do you think is going to win that one?
 > 
 > Besides, have you considered that it is that license you appear to
 > dislike so much which provides for the product, the hosting, the free
 > public machines, the support, all of that?  It's a pile of money and
 > time and I don't see RMS steppng forward with an open checkbook.
 > 
 > The license means we have a revenue stream.  We use a significant portion
 > of that revenue stream to help Linux.  If the revenue stream goes away
 > then so do the services we provide to you for free.  They obviously
 > have value or you wouldn't be using them.  
 > -- 
 > ---

Oh come on, you use Linux for testing and improving your software and
spin it in such a way that you do something charitable. From all your
mailings on this list I don't get the impression that you would do
anything that is not to improve your profit. I bet you can tax deduct
all that money you allegedly spend on linux and thereby increase your profit.

Anyway, this is no subject for the kernel list. Let those who want to
support Larry use bitkeeper and those who rather use free software use
something else.

Marcus

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: Bitkeeper

[Adrian Bunk]

On Fri, Jul 18, 2003 at 03:27:02PM -0700, Larry McVoy wrote:
> On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> > 	My understanding of the relevant case law in the United States is that
> > these types of restrictions are not allowed under copyright law itself.
> 
> On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > Actually your license is simply irrelevant in most of thre world. You
> > aren't allowed to forbid reverse engineering for interoperability.
> 
>     "Judge, I want to violate this license on this product that I got
>     for free because it's not free enough".
> 
>     "Judge, we give it out for free and we also developed technology
>     to transfer the data out of our product and into a GPLed product,
>     we do that at our expense and even host the competing GPLed repos
>     for free and they still want to violate the license"
> 
> Who do you think is going to win that one?
>...

"Judge, our current German copyright law explicitely states that such a
 clause is void."


> Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

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: Bitkeeper

[Larry McVoy]

On Sat, Jul 19, 2003 at 10:42:19PM +0200, Adrian Bunk wrote:
> On Fri, Jul 18, 2003 at 03:27:02PM -0700, Larry McVoy wrote:
> > On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> > > 	My understanding of the relevant case law in the United States is that
> > > these types of restrictions are not allowed under copyright law itself.
> > 
> > On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > > Actually your license is simply irrelevant in most of thre world. You
> > > aren't allowed to forbid reverse engineering for interoperability.
> > 
> >     "Judge, I want to violate this license on this product that I got
> >     for free because it's not free enough".
> > 
> >     "Judge, we give it out for free and we also developed technology
> >     to transfer the data out of our product and into a GPLed product,
> >     we do that at our expense and even host the competing GPLed repos
> >     for free and they still want to violate the license"
> > 
> > Who do you think is going to win that one?
> >...
> 
> "Judge, our current German copyright law explicitely states that such a
>  clause is void."

No, it isn't.  Your case law is based on a *purchase* or *lease* of a
product for *money*.  If you paid us money, you'd have a point.  But
you didn't.  You get to use the product for free and until there is 
some case law which says otherwise, we get to make any rules we like.
And our rules say you can't reverse engineer.  Too bad for you if you
don't like it, I'm not exactly overflowing with sympathy for someone 
who paid nothing and is now complaining that they aren't allowed to 
reverse engineer and steal what they didn't pay for.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Adrian Bunk]

On Sat, Jul 19, 2003 at 02:57:40PM -0700, Larry McVoy wrote:
> On Sat, Jul 19, 2003 at 10:42:19PM +0200, Adrian Bunk wrote:
> > On Fri, Jul 18, 2003 at 03:27:02PM -0700, Larry McVoy wrote:
> > > On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> > > > 	My understanding of the relevant case law in the United States is that
> > > > these types of restrictions are not allowed under copyright law itself.
> > > 
> > > On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > > > Actually your license is simply irrelevant in most of thre world. You
> > > > aren't allowed to forbid reverse engineering for interoperability.
> > > 
> > >     "Judge, I want to violate this license on this product that I got
> > >     for free because it's not free enough".
> > > 
> > >     "Judge, we give it out for free and we also developed technology
> > >     to transfer the data out of our product and into a GPLed product,
> > >     we do that at our expense and even host the competing GPLed repos
> > >     for free and they still want to violate the license"
> > > 
> > > Who do you think is going to win that one?
> > >...
> > 
> > "Judge, our current German copyright law explicitely states that such a
> >  clause is void."
> 
> No, it isn't.  Your case law is based on a *purchase* or *lease* of a

There is no case law in Germany. Case law is somethig that is only used 
in England and the USA.

In Germany there are laws for _everything_. Rules like who owns the
swarm of bees when several swarms of bees unite aren't made at court,
they are explicitely written in laws.

German judges don't read 200 years old judicial decisions, they read 
written laws.

Please ask a lawyer about the differences between the English/US and the 
continental Europe law system if you don't believe me.

> product for *money*.  If you paid us money, you'd have a point.  But
> you didn't.  You get to use the product for free and until there is 
> some case law which says otherwise, we get to make any rules we like.
> And our rules say you can't reverse engineer.  Too bad for you if you
> don't like it, I'm not exactly overflowing with sympathy for someone 
> who paid nothing and is now complaining that they aren't allowed to 
> reverse engineer and steal what they didn't pay for.

The current German copyright law doesn't talk about money. If you allow 
someone to use a copy the law explicitely states that some kind of 
contract clauses (e.g. a complete prohibition of disassembling) are 
simply void.

> Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

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: Bitkeeper

[Larry McVoy]

On Sun, Jul 20, 2003 at 12:28:38AM +0200, Adrian Bunk wrote:
> > product for *money*.  If you paid us money, you'd have a point.  But
> > you didn't.  You get to use the product for free and until there is 
> > some case law which says otherwise, we get to make any rules we like.
> > And our rules say you can't reverse engineer.  Too bad for you if you
> > don't like it, I'm not exactly overflowing with sympathy for someone 
> > who paid nothing and is now complaining that they aren't allowed to 
> > reverse engineer and steal what they didn't pay for.
> 
> The current German copyright law doesn't talk about money. If you allow 
> someone to use a copy the law explicitely states that some kind of 
> contract clauses (e.g. a complete prohibition of disassembling) are 
> simply void.

Alan pointed out to me that the EU rules are for interoperability and they
do not allow reverse engineering for the purposes of learning how a product
works.

Since BK can export any and *all* data and metadata from a one line command,
it's awfully hard to make the argument that you are reverse engineering 
for interoperability.  You can get your data as flat files, diffs, unified
diffs, context diffs.  You can get your checkin comments in any format you
want.  It's trivial to get data in and out of BK.  

You can even get all of that from a web server so you don't have to sully
your hands with evil BK software.

So where is the law that says it is OK to reverse engineer when the product
already provides everything you could possibly want for interoperability?
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Adrian Bunk]

On Sat, Jul 19, 2003 at 03:39:56PM -0700, Larry McVoy wrote:
> On Sun, Jul 20, 2003 at 12:28:38AM +0200, Adrian Bunk wrote:
> > > product for *money*.  If you paid us money, you'd have a point.  But
> > > you didn't.  You get to use the product for free and until there is 
> > > some case law which says otherwise, we get to make any rules we like.
> > > And our rules say you can't reverse engineer.  Too bad for you if you
> > > don't like it, I'm not exactly overflowing with sympathy for someone 
> > > who paid nothing and is now complaining that they aren't allowed to 
> > > reverse engineer and steal what they didn't pay for.
> > 
> > The current German copyright law doesn't talk about money. If you allow 
> > someone to use a copy the law explicitely states that some kind of 
> > contract clauses (e.g. a complete prohibition of disassembling) are 
> > simply void.
> 
> Alan pointed out to me that the EU rules are for interoperability and they
> do not allow reverse engineering for the purposes of learning how a product
> works.
> 
> Since BK can export any and *all* data and metadata from a one line command,
> it's awfully hard to make the argument that you are reverse engineering 
> for interoperability.  You can get your data as flat files, diffs, unified
> diffs, context diffs.  You can get your checkin comments in any format you
> want.  It's trivial to get data in and out of BK.  
> 
> You can even get all of that from a web server so you don't have to sully
> your hands with evil BK software.
> 
> So where is the law that says it is OK to reverse engineer when the product
> already provides everything you could possibly want for interoperability?

Current German copyright law says things like that clauses that forbit 
to gather information about the ideas behind a program through normal 
program usage are void.

IANAL, and we are entering an area where you need a lawyer that reads 
both your licensing terms and the copyright law to tell exactly what is 
allowed and what isn't allowed.

My main point is:
There are countries that have laws that are different from US laws (yes,
there's a world outside the USA...). If I download software from your
server it is possible that my local law is the one that is valid for the
contract between us (independent of whether I pay for the software or
whether you give it for free) and my local laws might be different from
the jurisdiction in the USA.

> Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

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: Bitkeeper

[Larry McVoy]

On Sun, Jul 20, 2003 at 01:45:19AM +0200, Adrian Bunk wrote:
> There are countries that have laws that are different from US laws (yes,
> there's a world outside the USA...). If I download software from your
> server it is possible that my local law is the one that is valid for the
> contract between us (independent of whether I pay for the software or
> whether you give it for free) and my local laws might be different from
> the jurisdiction in the USA.

Let's try and simplify this because having a legal discussion is pointless.
Our position is that we gave something out for free with an understanding
that you wouldn't reverse engineer it.  Regardless of your legal rights or
lack thereof, should you attempt to reverse engineer BK we'll simply stop
giving BK out for free.  See?  Simple.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Tupshin Harper]

Larry McVoy wrote:

>On Sun, Jul 20, 2003 at 01:45:19AM +0200, Adrian Bunk wrote:
>  
>
>>There are countries that have laws that are different from US laws (yes,
>>there's a world outside the USA...). If I download software from your
>>server it is possible that my local law is the one that is valid for the
>>contract between us (independent of whether I pay for the software or
>>whether you give it for free) and my local laws might be different from
>>the jurisdiction in the USA.
>>    
>>
>
>Let's try and simplify this because having a legal discussion is pointless.
>Our position is that we gave something out for free with an understanding
>that you wouldn't reverse engineer it.  Regardless of your legal rights or
>lack thereof, should you attempt to reverse engineer BK we'll simply stop
>giving BK out for free.  See?  Simple.
>  
>
No, it's not simple (and this part, unlike much of the rest of this 
discussion, is relevant to this list). If you stopped giving it out for 
free, then it would cease to be a viable tool for Linux development.

-Tupshin

Re: Bitkeeper

[Valdis.Kletnieks]

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

On Sat, 19 Jul 2003 17:10:05 PDT, Tupshin Harper said:

> No, it's not simple (and this part, unlike much of the rest of this 
> discussion, is relevant to this list). If you stopped giving it out for 
> free, then it would cease to be a viable tool for Linux development.

It's called "Killing the goose that lays the golden eggs".

And although Larry has his philanthropic side, if he has to decide between
"helping Linux development" and "making sure the bills get paid".....


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

Re: Bitkeeper

[Jeff Garzik]

THIS IS NOT A BITKEEPER LIST.

Thanks,

	Jeff

Re: Bitkeeper

[Jeff Garzik]

LINUX KERNEL IS NOT A BITKEEPER MAILING LIST.

Regards,

	Jeff

Re: Bitkeeper

[jiho]

Larry McVoy wrote:
> Let's try and simplify this because having a legal discussion is pointless.
> Our position is that we gave something out for free with an understanding
> that you wouldn't reverse engineer it.  Regardless of your legal rights or
> lack thereof, should you attempt to reverse engineer BK we'll simply stop
> giving BK out for free.  See?  Simple.

Now that *is* legal, and reasonable (in the legal sense) as well.


-- Jim Howard  <jiho@c-zone.net>

Re: Bitkeeper

[Valdis.Kletnieks]

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

On Sat, 19 Jul 2003 17:02:32 PDT, Larry McVoy said:
> Let's try and simplify this because having a legal discussion is pointless.
> Our position is that we gave something out for free with an understanding
> that you wouldn't reverse engineer it.  Regardless of your legal rights or
> lack thereof, should you attempt to reverse engineer BK we'll simply stop
> giving BK out for free.  See?  Simple.

You know guys, Larry would spend a lot less time having to make threats
like this if people didn't start off by saying "Let's see how we can get a free
Bitkeeper".   I've seen *LOTS* of philosophical posturing and arguing about
whether it's moral to rip Larry's software off, and what countries make it legal
to do so.

I've only seen *ONE* person (who's name I've forgotten but who needs to be
praised) suggest finding some *FUNDING* for Larry so he doesn't worry about his
revenue stream getting hosed.

So Larry - *IF* funding was there, would you consider a business model similar
to Hans Reiser's?


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

Re: Bitkeeper

[Larry McVoy]

On Sat, Jul 19, 2003 at 08:30:53PM -0400, Valdis.Kletnieks@vt.edu wrote:
> So Larry - *IF* funding was there, would you consider a business model similar
> to Hans Reiser's?

I'd consider anything which resulted in a healthy business.  The choices
we've made to date have been 100% focussed on staying healthy so we can
grow as a company and continue to support Linux (and the other open
source guys, but I personally only care about Linus - he's unique),
and our commercial customers.  We've been approached by investors and
companies which wished to buy us outright and I passed on both because
it was clear that they wanted one thing: money.  They would have shut
down the free use of BK in less than a day after the deal was done.

The thing you need to consider is that the Linux community is not that
different than our commercial customers - both need us to be healthy so
that we can support them.  Healthy costs a lot of money.

Part of the problem is that people are extremely short sighted.  Until we
gave you BK nobody had any idea that a system like this was possible.
We can see a lot of problems with BK and a lot of problems in the
development process of Linux (and other systems) that maybe we can help
make easier.  When people think about funding us they think about the
$$$ it would take to have a couple of guys doing bug fixes.  That's not
good enough.  We need the dollars to do the next thing that helps make
development work better.  BK is fine but it is not the end all answer.
There is a lot of work in bug tracking, project management, review tools,
web interfaces, etc.  We're not going to be interested in any business
model that means we get enough money to fix some bugs but not enough to
solve the next set of problems.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Jeff Garzik]

THIS IS NOT A BITKEEPER MAILING LIST.

Thank you,

	Jeff

Re: Bitkeeper

[jiho]

(I spared the list a couple of messages by forgetting to CC 'em....)


Larry McVoy wrote:
> On Sat, Jul 19, 2003 at 04:53:40PM -0700, jiho@c-zone.net wrote:
> 
>>Larry McVoy wrote:
>>
>>>So where is the law that says it is OK to reverse engineer when the product
>>>already provides everything you could possibly want for interoperability?
>>
>>Antitrust law.  The purpose of antitrust law is to further competition, not 
>>merely interoperability.
> 
> The day I'm worried about antitrust law is the day I'm rich enough to retire.

I infer a creeping sense of humor.


-- Jim Howard  <jiho@c-zone.net>

Re: Bitkeeper

[Pavel Machek]

Hi!

> > 	My understanding of the relevant case law in the United States is that
> > these types of restrictions are not allowed under copyright law itself.
> 
> On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > Actually your license is simply irrelevant in most of thre world. You
> > aren't allowed to forbid reverse engineering for interoperability.
> 
>     "Judge, I want to violate this license on this product that I got
>     for free because it's not free enough".

Its not free at all.

Alan is right, that parts of licence agreement are irrelevant in
Europe, and what RMS is suggesting is perfectly legal here. Like it or
not. Don't try to make "RMS suggested something ilegal" case. Thanx,
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Bitkeeper

[Jörn Engel]

On Fri, 18 July 2003 15:51:36 -0400, Richard Stallman wrote:
> 
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.

I've told other people before and I'll tell you again:
Please, pretty please, leave linux-kernel for discussions about the
linux kernel and leave the bitkeeper flames for those that enjoy
electronic pyrotechnic.

Apart from that: Larry is right.  Noone cared about crappy ol' cvs
until bk came alone and showed what everyone already knew.  If you
didn't have to improve cvs back then, it is still as good as it was,
so thy improve it now?  Pure jealousy?

Jörn

-- 
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown

Re: Bitkeeper

[Svein Ove Aas]

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

fredag 18. juli 2003, 23:06, skrev Jörn Engel:
> On Fri, 18 July 2003 15:51:36 -0400, Richard Stallman wrote:
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper, and for Linux developers to start switching
> > to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> > if he carries out these threats, he risks alienating the community
> > that he hopes will market Bitkeeper for him.
>
> I've told other people before and I'll tell you again:
> Please, pretty please, leave linux-kernel for discussions about the
> linux kernel and leave the bitkeeper flames for those that enjoy
> electronic pyrotechnic.
>
> Apart from that: Larry is right.  Noone cared about crappy ol' cvs
> until bk came alone and showed what everyone already knew.  If you
> didn't have to improve cvs back then, it is still as good as it was,
> so thy improve it now?  Pure jealousy?

No, I think we'd improve CVS because bk came along and showed us what we 
already knew.

Bitkeeper *is* better, but as long as the ideas those improvements are based 
on don't get patented there is no reason for us not to claim them for 
ourselves.

Summa summarum:
Having a Free CVS is good.
Having a useful BitKeeper is sometimes better.
Having a Free CVS with all the features of BK would be best.


- - Svein Ove Aas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/GG4H9OlFkai3rMARAkt/AKCdvO7UCiK2AdBKZg0sSoXghmW6vgCfedcB
zKSd79Dwa/ZPwijYMtR3lO0=
=Xuj7
-----END PGP SIGNATURE-----

BK is not heaven, sure [Was: Re: Bitkeeper]

[J.A. Magallon]

On 07.19, Svein Ove Aas wrote:
[...]
> 
> Summa summarum:
> Having a Free CVS is good.
> Having a useful BitKeeper is sometimes better.
> Having a Free CVS with all the features of BK would be best.
> 

Oh, please, stop thinking BitKeeper is the best thing since sliced bread !!!
I have never used BK. I just use CVS as client. I have not looked at SVN.
BK sure surpasses every other SCM tool.
But please, stop thinking about BK clones, BK features, all BK.

As I read in some posts in this thread, people is doing useful work on
a free SCM. Could you all put your efforts on generating a list of
features/requirements you would like for a SCM system specialized for kernel
development, and send them to the developers, instead of arguing about
legal impact of reverse-engineering BK. And let the developers think about
protocols, work flow, ways to do things, and so on. They can find a way
not even similiar to the BK one, and even better...

That way perhaps in one year you could suck data from BK and at least try
a new system...

-- 
J.A. Magallon <jamagallon@able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.22-pre6-jam1m (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-0.3mdk))

Re: Bitkeeper

[James Simmons]

These threads are getting annoying :-<

offtopic crap (was Re: Bitkeeper)

[David S. Miller]

On Sat, 19 Jul 2003 00:50:46 +0100 (BST)
James Simmons <jsimmons@infradead.org> wrote:

> These threads are getting annoying :-<

I agree.  As vger postmaster I think I'll start shitcanning them, but
unfortunately most of these threads startup while I'm sleeping so it's
hard for me to get a regexp in place to block the thread.

So, let me put it this way, if you start a BK flame thread it is _YOU_
who I will blacklist from posting to vger.kernel.org

Re: offtopic crap (was Re: Bitkeeper)

[Jeff Garzik]

David S. Miller wrote:
> So, let me put it this way, if you start a BK flame thread it is _YOU_
> who I will blacklist from posting to vger.kernel.org


No more horribly-offtopic RMS trolls?  :)

	Jeff

Re: Bitkeeper

[Zack Brown]

Hi folks,

On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
>     > If you are trying to copy BK, give it up.  We'll simply follow in the
>     > footsteps of every other company faced with this sort of thing and change
>     > the protocol every 6 months.  Since you would be chasing us you can never
>     > catch up.  If you managed to stay close then we'd put digital signatures
>     > into the protocol to prevent your clone from interoperating with BK.
> 
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.

I'm against Richard inflaming the situation without really helping, but since
the issue's come up again, I just thought I'd put in a good word for arch here:

The arch project is no longer just a bunch of shell scripts. Tom
Lord has rewritten it in C (and called the C version 'tla'), and it's
self-hosting. Developers are actually contributing to development using arch
itself now. These seem like very big milestones to me.

There's still quite a bit of work to do on it (and a steep learning curve), but
personally, I think it's the project with the best chance of success. Anyone
who's interested in this issue might consider contributing to arch development
instead of duking it out on lkml.

Be well,
Zack

> -
> 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/

-- 
Zack Brown

BitKeeper

[Amit Vijairania]

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

Hi!

I want to contribute to Reiser4, and would like to dowload latest
development source.   Namesys.com gives  directions for using BitKeeper
repositories.  Is this the only way to download latest code?

Thank you.

Amit

[-- Attachment #2: Type: text/html, Size: 308 bytes --]

Re: BitKeeper

[Yoanis Gil Delgado]

On Tuesday 07 March 2006 11:23, Amit Vijairania wrote:
> Hi!
>
> I want to contribute to Reiser4, and would like to dowload latest
> development source.   Namesys.com gives  directions for using BitKeeper
> repositories.  Is this the only way to download latest code?
>
> Thank you.
>
> Amit
if you want to contribute to reiser4, maybe you would like to participate in 
the plugin fest. 

Re: BitKeeper

[Amit Vijairania]

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

Definitely...  But, I am new to Reiser4 and need some information.

Thanks,
Amit

On 3/7/06, Yoanis Gil Delgado <fred@uh.cu> wrote:
>
> On Tuesday 07 March 2006 11:23, Amit Vijairania wrote:
> > Hi!
> >
> > I want to contribute to Reiser4, and would like to dowload latest
> > development source.   Namesys.com gives  directions for using BitKeeper
> > repositories.  Is this the only way to download latest code?
> >
> > Thank you.
> >
> > Amit
> if you want to contribute to reiser4, maybe you would like to participate
> in
> the plugin fest.
>

[-- Attachment #2: Type: text/html, Size: 931 bytes --]

Re: BitKeeper

[Yoanis Gil Delgado]

On Tuesday 07 March 2006 12:08, Amit Vijairania wrote:
> Definitely...  But, I am new to Reiser4 and need some information.
>
> Thanks,
> Amit
>
> On 3/7/06, Yoanis Gil Delgado <fred@uh.cu> wrote:
> > On Tuesday 07 March 2006 11:23, Amit Vijairania wrote:
> > > Hi!
> > >
> > > I want to contribute to Reiser4, and would like to dowload latest
> > > development source.   Namesys.com gives  directions for using BitKeeper
> > > repositories.  Is this the only way to download latest code?
> > >
> > > Thank you.
> > >
> > > Amit
> >
> > if you want to contribute to reiser4, maybe you would like to participate
> > in
> > the plugin fest.
Well if you need some help with the debuggin an all that i can help. I have 
setup an UML box with reiser4 support.

Re: BitKeeper

[Hans Reiser]

I should mention that we don't use bitkeeper.....

Re: BitKeeper

[Hans Reiser]

flx, please fix bitkeeper related web pages.

Hans

Yoanis Gil Delgado wrote:

>On Tuesday 07 March 2006 11:23, Amit Vijairania wrote:
>  
>
>>Hi!
>>
>>I want to contribute to Reiser4, and would like to dowload latest
>>development source.   Namesys.com gives  directions for using BitKeeper
>>repositories.  Is this the only way to download latest code?
>>
>>Thank you.
>>
>>Amit
>>    
>>
>if you want to contribute to reiser4, maybe you would like to participate in 
>the plugin fest. 
>
>
>  
>

Re: BitKeeper

[Peter van Hardenberg]

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

Hans,

I'd like to run a mirror of the R4 dev tree so that the R4 dev wiki can 
reference specific files and versions of files as well as the changelog.

You mentioned R4 development is done using git these days. Is that repository 
public, or at least publicly mirrorable?

-p

On Tuesday 07 March 2006 10:31, Hans Reiser wrote:
> flx, please fix bitkeeper related web pages.
>
> Hans
>
> Yoanis Gil Delgado wrote:
> >On Tuesday 07 March 2006 11:23, Amit Vijairania wrote:
> >>Hi!
> >>
> >>I want to contribute to Reiser4, and would like to dowload latest
> >>development source.   Namesys.com gives  directions for using BitKeeper
> >>repositories.  Is this the only way to download latest code?
> >>
> >>Thank you.
> >>
> >>Amit
> >
> >if you want to contribute to reiser4, maybe you would like to participate
> > in the plugin fest.

-- 
Peter van Hardenberg (pvh@pvh.ca)
Victoria, BC, Canada

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

Bitkeeper

[Paul Dorman]

Hi everyone,

noticed a furore on Slashdot yesterday over Bitmover dropping support
for the free version of Bitkeeper.

http://www.bitkeeper.com/press/2005-04-05.html 

You may hear the "I told you so's" in the distance if you listen
carefully :o)

In the meantime, what will the wonderful Xen project leaders do?

Regards,
Paul

Re: Bitkeeper

[Jacob Gorm Hansen]

Paul Dorman wrote:
> Hi everyone,
> 
> noticed a furore on Slashdot yesterday over Bitmover dropping support
> for the free version of Bitkeeper.
> 
> http://www.bitkeeper.com/press/2005-04-05.html 
> 
> You may hear the "I told you so's" in the distance if you listen
> carefully :o)

I have been tracking Xen with TLA/Arch ever since getting involved, and 
that has worked really fine for me.  These days there is also the 
Ubuntu-sponsored Bazaar, which I think is mostly Arch-compatible, but 
with command line syntax closer to what BK and CVS users may expect. The 
only problem with Arch and Xen is that Arch really works best if your 
build-targets live in their own directory, rather being littered all 
over the source tree. It can be convinced to ignore all the unversioned 
stuff, but I think what usually happens is that Arch manages to convince 
its users to modify the build scripts (saves a lot of 'make clean && 
make's too if you do it right and makes the source tree easier to 
navigate) rather than the other way around.

The good news is that with all these great new tools coming out, 
tracking an upstream code base has become a lot simpler than it used to 
be, making it easier for users to run with whatever system they prefer.

Personally, I'll stick with TLA/Arch.

Jacob

Re: Bitkeeper

[Tupshin Harper]

Jacob Gorm Hansen wrote:

> I have been tracking Xen with TLA/Arch ever since getting involved, 
> and that has worked really fine for me. 

Cool. I'm interested in tracking it with darcs, myself. I'm curious what 
process/scripts you're using to do the tracking.

Thanks

-Tupshin

Re: Bitkeeper

[Jacob Gorm Hansen]

hTupshin Harper wrote:
> Jacob Gorm Hansen wrote:
> 
>> I have been tracking Xen with TLA/Arch ever since getting involved, 
>> and that has worked really fine for me. 
> 
> 
> Cool. I'm interested in tracking it with darcs, myself. I'm curious what 
> process/scripts you're using to do the tracking.

I did the initial import manually from a tarball, using 'tla add' to add 
all files by hand (actually, I did 'tla tree-lint -t |xargs tla add' 
repeatedly, until all dirs and files were added), and I use the 
following script to stay up to date:

(My archive is called xen, branch is called 'unstable', version is 3.0)

------------------------------------------
tla get xen--unstable--3.0 xen--unstable--3.0

(       cd xen--unstable--3.0
         tla inventory -s | xargs rm -rf )

wget 
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-unstable-src.tgz

tar xfz xen-unstable-src.tgz

cp -ra xen-unstable/* xen--unstable--3.0
------------------------------------------

I run the script in an empty directory, and it leaves me with a 
xen--unstable--3.0 checkout containing the upstream changes. I cd in 
there, and run

tla tree-lint

To see if there are any new, renamed* or deleted files that tla needs to 
know about. I then add, rename or delete as needed, and when tree-lint 
is happy I can 'tla commit'.

I keep my own changes in a separate branch, called xen--whatever--3.0, 
and do all my work there. To replay upstream changes into my own branch, 
I use 'tla star-merge -t xen--unstable--3.0', resolve any conflicts, and 
'tla commit'.

I have seen better automated approaches, but the method above works fine 
for me, leaves me in full control, and generally takes less than five 
minutes to complete.

Jacob


*) in case of a renamed directory, e.g. a new linux version number, I 
generally start over after having performed the directory-rename by hand 
in another checkout, as otherwise I will end up with multiple 
directories with the same content.

Re: Bitkeeper

[Scott Parish]

On Thu, Apr 07, 2005 at 04:26:47PM -0700, Tupshin Harper wrote:

> Jacob Gorm Hansen wrote:
> 
> Cool. I'm interested in tracking it with darcs, myself. I'm curious what 
> process/scripts you're using to do the tracking.

cd ~/darcs/BK-xen-unstable
~/bin/bk_client-1.1/update bk://xen.bkbits.net/xeno-unstable.bk
darcs add -r *
darcs record -am "merge with bk://xen.bkbits.net/xeno-unstable.bk"

I keep BK-xen-unstable as a clean mirror, updated daily. For dev
work i branch off that, and stay in sync using "darcs pull".
Unfortunately, this isn't granular to individual bk patches, and
renames show up as del/adds.

sRp

-- 
Scott Parish

Re: Bitkeeper

[Jacob Gorm Hansen]

Scott Parish wrote:
> On Thu, Apr 07, 2005 at 04:26:47PM -0700, Tupshin Harper wrote:
> 
> cd ~/darcs/BK-xen-unstable
> ~/bin/bk_client-1.1/update bk://xen.bkbits.net/xeno-unstable.bk
> darcs add -r *
> darcs record -am "merge with bk://xen.bkbits.net/xeno-unstable.bk"
> 
> I keep BK-xen-unstable as a clean mirror, updated daily. For dev
> work i branch off that, and stay in sync using "darcs pull".
> Unfortunately, this isn't granular to individual bk patches, and
> renames show up as del/adds.

The advantage to the more manual approach is that you can track renames, 
but you can probably do that with darcs as well. From what I have heard, 
the main problem with darcs is that is uses lots of memory when 
operating on big trees, and that it is a bit slow due to having been 
written in Haskell. It does seem simpler to use than TLA/Arch however, 
but Bazaar tries to address that (though I don't think this is an issue 
once you get used to TLA.)

With the recently announced open source bk client I suppose one could 
create a script that would automatically track bk changes on a 
per-changeset basis, including renames.

Jacob

Re: Bitkeeper

[Scott Parish]

On Thu, Apr 07, 2005 at 05:21:15PM -0700, Jacob Gorm Hansen wrote:

> From what I have heard, the main problem with darcs is that is uses
> lots of memory when operating on big trees, and that it is a bit
> slow due to having been written in Haskell.

darcs has been fast enough for xen; linux is a completely different
story :)

sRp

-- 
Scott Parish

Re: Bitkeeper

[Chris Wright]

* Jacob Gorm Hansen (jacobg@diku.dk) wrote:
> With the recently announced open source bk client I suppose one could 
> create a script that would automatically track bk changes on a 
> per-changeset basis, including renames.

It might be tough.  That bk client doesn't really give you a bk repo.
It gives you a source tree and a file called ChangeLog, but no other
metadata.  So associating entries in ChangeLog with actual csets is best
guess.  You can pull a specific revision, so that plus a forest of cp
-rl trees and diff -Naur is conceptually feasible.  But I'm not sure how
well it would preserve bk merges.

thanks,
-chris

Re: Bitkeeper

[Sean Perry]

Jacob Gorm Hansen wrote:
> 
> The advantage to the more manual approach is that you can track renames, 
> but you can probably do that with darcs as well. From what I have heard, 
> the main problem with darcs is that is uses lots of memory when 
> operating on big trees, and that it is a bit slow due to having been 
> written in Haskell. It does seem simpler to use than TLA/Arch however, 
> but Bazaar tries to address that (though I don't think this is an issue 
> once you get used to TLA.)
> 

Haskell is a bit slower, but the real culprit is design related. The 
author and crew are working on it. Should be cleared up eventually.

Re: Bitkeeper

[Jacob Gorm Hansen]

Sean Perry wrote:

> Haskell is a bit slower, but the real culprit is design related. The 
> author and crew are working on it. Should be cleared up eventually.

Hmm, the Wiki page about darcs performance looks rather scary:

http://www.scannedinavian.org/DarcsWiki/Performance

And quoting from the "Best Practices" page at

http://www.scannedinavian.org/DarcsWiki/BestPractices :

"Also, very large conflicts and complex conflicts can cause darcs to use 
an exponential amount of CPU power to solve the problem, giving the 
appearance that darcs is "spinning" or "hanging""

 From what I have read about darcs, the problem is the 'theory of 
patches' approach which demands that all patches be loaded into memory 
at once so that the order in which they should be applied can be 
determined via a n*n comparison of the contents of each patch against 
the contents of all other patches. While all this talk of quantum 
operators may sound sexy at first, I am fairly sure it is vastly 
overkill for real-world source-control.

I other words, I would not be too optimistic about darcs having its 
performance issues cleared up in the shorter term. Besides, there is the 
issue of using a tool written in a language that the majority of 
programmers will find hard to understand*.

Jacob

* Not me of course, I was exposed to Miranda at an early age ;-)

Re: Bitkeeper

[David Hopwood]

Jacob Gorm Hansen wrote:
> From what I have read about darcs, the problem is the 'theory of 
> patches' approach which demands that all patches be loaded into memory 
> at once so that the order in which they should be applied can be 
> determined via a n*n comparison of the contents of each patch against 
> the contents of all other patches.

I don't know precisely why the current darcs implementation needs as
much memory as it does, but I know it is not for the above reason. An
important property of the 'theory of patches' is that merges can be done
in arbitrary order (see <http://abridgegame.org/darcs/manual/node8.html>).

The size of a merged patch will be similar to the sum of the sizes of the
input patches, just as in other SCSs. A very simple-minded implementation
that literally reconstructs the whole repository by patching an empty one
would require memory proportional to the repository size, but there's
nothing about the theory that would require you to handle the whole
repository at once.

 > Hmm, the Wiki page about darcs performance looks rather scary:
 >
 > http://www.scannedinavian.org/DarcsWiki/Performance

Those look like implementation nits to me, with known workarounds.

Also remember that other SCSs only support what darcs calls 'hunk patches'.
IIUC, it's only if you use features of darcs that are not present in other
SCSs that you hit the exponential complexity cases that are mentioned on the
wiki page.

That said, I've heard reports that the current darcs implementation can get
a repository into states that require an understanding of its internals to
get out of. It wouldn't be the only SCS that has that property, but people
may be more used to the particular ways in which CVS et al get confused.

> While all this talk of quantum operators may sound sexy at first, I am
> fairly sure it is vastly overkill for real-world source-control.

<sigh>. From a marketing point of view, even mentioning quantum mechanics
is a disaster. It might have been fine when the audience for darcs was three
physicists, but that page really should be rewritten. Anyway, the limit of
the analogy between QM and darcs' theory of patches is that they both involve
commutative operators; that's all.

> I other words, I would not be too optimistic about darcs having its 
> performance issues cleared up in the shorter term. Besides, there is the 
> issue of using a tool written in a language that the majority of 
> programmers will find hard to understand*.

The majority of programmers would have difficulty in understanding an SCS
implementation written in any language. Plenty of programmers understand
Haskell.

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>

RE: Bitkeeper

[Brown, Len]

hang on a sec, tree update is in transit.

2.6.8 is still the latest till you hear from me... 

>-----Original Message-----
>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
>[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
>Nathan Bryant
>Sent: Monday, August 16, 2004 5:43 PM
>To: Brown, Len
>Cc: ACPI Developers
>Subject: [ACPI] Bitkeeper
>
>
>Looks like linux-acpi-test-2.6.9 doesn't have the same set of 
>changesets 
>as test-2.6.9. I'm not sure why the sudden change in nomenclature or 
>which to pull from going forward...
>
>Nathan
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>Acpi-devel mailing list
>Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/acpi-devel
>


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Bitkeeper

[Nathan Bryant]

Looks like linux-acpi-test-2.6.9 doesn't have the same set of changesets 
as test-2.6.9. I'm not sure why the sudden change in nomenclature or 
which to pull from going forward...

Nathan


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Bitkeeper

[John Bradford]

> Any investment into writing a new source management
> system would be better served by improving the linux source code.

What happens if somebody develops a really good versioned filesystem
for Linux, would it not get merged, because the linux kernel would
then contain SCM-like functionality?

John.

Re: Bitkeeper

[Mark Mielke]

On Sat, Jul 19, 2003 at 05:00:24PM +0100, John Bradford wrote:
> > Any investment into writing a new source management
> > system would be better served by improving the linux source code.
> What happens if somebody develops a really good versioned filesystem
> for Linux, would it not get merged, because the linux kernel would
> then contain SCM-like functionality?

One day, when it happens, we'll see what ripple effects it has.

In most cases, however, I suspect that a versioned file system will never
be a replacement for a good source management system. The lines could become
blurred, but the 'good versioned file system' might take the form a kernel
module that allowed SCM systems to plug into it, at which point, Bit Keeper
might plug into it, and everybody would be happy. I doubt you want to put
merge manager functionality into the kernel, or many of the other components
of a good source management system. The storage and access is one of the
lesser concerns. Bit Keeper uses similar storage and access methods as
SCCS, does it not?

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: Bitkeeper

[John Bradford]

> If everyone spent the time replacing bitkeeper instead of beating up
> Larry they'd get a lot further.

Linux isn't the only free operating system in existance, and although
BK seems to suit the requirements of a lot of Linux developers, that
doesn't mean that it meets the requirements of other free OS
development teams.

I strongly suspect that we'll see a free SCM developed after a few
more years of HURD development, for example.

Doesn't mean we'll switch to it, though, we haven't switched to my bug
database, have we?  :-).

John.

BitKeeper

[John Bradford]

The re-occuring thread about BitKeeper, and the appropriateness of
using a closed-source tool to develop open source software is here yet
again, and I'd just like to point out a few things:

1. Linus chose to use BitKeeper, presumably because it makes his work
easier.

2. If people annoy Larry enough, he can stop providing hosting for us
at bkbits, and stop providing new BitKeeper versions.

If anybody ends up making point number 2 happen, do you think Linus is
going to be happy about it?

Regardless of your views on closed-source software, that is something
to think about.

Linux is an open source project - anybody is free to fork it and
maintain their own tree, but so far nobody has.  Quite the opposite,
infact - everybody is trying to get their patches accepted in to
Linus' tree.

If you don't like BitKeeper, why not write an alternative?

John.

Re: BitKeeper

[Pavel Machek]

Hi!

> The re-occuring thread about BitKeeper, and the appropriateness of
> using a closed-source tool to develop open source software is here yet
> again, and I'd just like to point out a few things:
> 
> 1. Linus chose to use BitKeeper, presumably because it makes his work
> easier.
> 
> 2. If people annoy Larry enough, he can stop providing hosting for us
> at bkbits, and stop providing new BitKeeper versions.
> 
> If anybody ends up making point number 2 happen, do you think Linus is
> going to be happy about it?

Actually, Larry can

3. Create new version of bitkeeper that says you can not use it. You
have to download new version.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: BitKeeper

[John Bradford]

> > The re-occuring thread about BitKeeper, and the appropriateness of
> > using a closed-source tool to develop open source software is here yet
> > again, and I'd just like to point out a few things:
> > 
> > 1. Linus chose to use BitKeeper, presumably because it makes his work
> > easier.
> > 
> > 2. If people annoy Larry enough, he can stop providing hosting for us
> > at bkbits, and stop providing new BitKeeper versions.
> > 
> > If anybody ends up making point number 2 happen, do you think Linus is
> > going to be happy about it?
> 
> Actually, Larry can
> 
> 3. Create new version of bitkeeper that says you can not use it. You
> have to download new version.

See the part of my original post that you haven't quoted:

http://marc.theaimsgroup.com/?l=linux-kernel&m=104529737310430&w=2

I am not advocating the use of BitKeeper, nor am I advocating the use
of any non-free software.

All I am advocating is not deliberately trying to annoy people who are
developing free software.

John.

bitkeeper

[Cameron, Steve]

Hi, everybody.  (I'm not trying to start a flamewar here, really.)

I couldn't help but notice the recent discussion/flamewar about the
bitkeeper license changes over on LKML.  These changes, as I
understand them, impact anybody who develops or distributes
software deemed to compete with bitkeeper.

In my experience, powerpc linux development seems to rely
on bitkeeper much more so than the regular linux kernel
development, by which I mean that if you want to keep up
to date with powerpc linux kernel, you pretty much have to
use bitkeeper, or at least that's been my experience.   And,
since I have personally contributed to CVS development in
the past, and odds are, will again in the future, I thknk
maybe this means I can't use bitkeeper anymore (well, not for free).
So that leaves me in a bit of a tight spot.

So, I was wondering if there are any plans to say, mirror
the development linux powerpc bitkeeper tree as a tar.bz2
on a more regular basis, like the regular linux kernel
development team does?  Or perhaps someone is already
doing that, and I just don't know about it?

This is not exactly urgent for me right now, as I've not
been working on powerpc lately, but probably will be getting
back to it sometime not far away.  If I'm the only one in this
position perhaps it would be possible for me to get an up-to-date
tree from someone on an as-needed basis?

Thanks,

-- steve

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: bitkeeper

[Cort Dougan]

If you're unclear on the bitkeeper license I'd suggest you ask Larry.  I'm
sure he'd be happy to answer any questions on the license and how it
affects your situation.

} the past, and odds are, will again in the future, I thknk
} maybe this means I can't use bitkeeper anymore (well, not for free).
} So that leaves me in a bit of a tight spot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: bitkeeper

[Hollis Blanchard]

On Mon, 14 Oct 2002, Cameron, Steve wrote:
>
> So, I was wondering if there are any plans to say, mirror
> the development linux powerpc bitkeeper tree as a tar.bz2
> on a more regular basis, like the regular linux kernel
> development team does?  Or perhaps someone is already
> doing that, and I just don't know about it?

MontaVista already provides rsync access to the PPC bk trees. See
http://penguinppc.org/dev/kernel.shtml for more details.

-Hollis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: bitkeeper

[fred]

I am behind firewall. I can use neither rsync nor bk. I miss tar.bz2 packet.

-----Original Message-----
From: Hollis Blanchard [mailto:hollis@austin.ibm.com]
Sent: Monday, October 14, 2002 4:26 PM
To: Cameron, Steve
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: bitkeeper


On Mon, 14 Oct 2002, Cameron, Steve wrote:
>
> So, I was wondering if there are any plans to say, mirror
> the development linux powerpc bitkeeper tree as a tar.bz2
> on a more regular basis, like the regular linux kernel
> development team does?  Or perhaps someone is already
> doing that, and I just don't know about it?

MontaVista already provides rsync access to the PPC bk trees. See
http://penguinppc.org/dev/kernel.shtml for more details.

-Hollis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: bitkeeper

[Kenneth Johansson]

On Tue, 2002-10-15 at 10:45, fred wrote:
>
> I am behind firewall. I can use neither rsync nor bk. I miss tar.bz2 packet.

BK works over http also and can be used with a http proxy.

export http_proxy=http://proxy:80

Do not forget the port number BK do not try on port 80 by default as a
lot of other programs do.



--
Kenneth Johansson
Ericsson AB                       Tel: +46 8 404 71 83
Borgafjordsgatan 9                Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@etx.ericsson.se


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/