Hi!
I've created little project for read-only (for now ;-) bitkeeper
clone. It is available at http://www.sf.net/projects/bitbucket (no tar balls,
just get it fresh from CVS).
Part of readme follows.
Install CSSC from <http://cssc.sf.net/> (it is also available as
Debian package). You may need to apply cssc.diff.
Here you get following tools:
bcheckout_HEAD:
extracts files from BK repository. You can get repository
by rsync -zav --delete nl.linux.org::kernel/linux-2.5 .
bpull:
pull new version of repository, compute differences from
the last time and apply them to directory with *your*
sources.
bdiff:
compare two versions (specify versions from top-level
s.ChangeSet)
To get a list of all changesets, do prs linux-2.5/SCCS/s.ChangeSet.
Enjoy, and help me make it usefull,
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
BitKeeper is a trademark, please don't use the BitKeeper name when
describing BitBucket. Thanks.
On Wed, Feb 26, 2003 at 09:02:12PM +0100, Pavel Machek wrote:
> Hi!
>
> I've created little project for read-only (for now ;-) bitkeeper
> clone. It is available at http://www.sf.net/projects/bitbucket (no tar balls,
> just get it fresh from CVS).
>
> Part of readme follows.
>
>
> Install CSSC from <http://cssc.sf.net/> (it is also available as
> Debian package). You may need to apply cssc.diff.
>
> Here you get following tools:
>
> bcheckout_HEAD:
> extracts files from BK repository. You can get repository
> by rsync -zav --delete nl.linux.org::kernel/linux-2.5 .
>
> bpull:
> pull new version of repository, compute differences from
> the last time and apply them to directory with *your*
> sources.
>
> bdiff:
> compare two versions (specify versions from top-level
> s.ChangeSet)
>
> To get a list of all changesets, do prs linux-2.5/SCCS/s.ChangeSet.
>
> Enjoy, and help me make it usefull,
> Pavel
> --
> When do you have a heart between your knees?
> [Johanka's followup: and *two* hearts?]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Mar 01, 2003 at 07:28:20AM -0800, Larry McVoy wrote:
> BitKeeper is a trademark, please don't use the BitKeeper name when
> describing BitBucket. Thanks.
I think he's allowed to use the name so long as he only uses it to
describe what the purpose of the tool is and recognizes in the same
document who the holder of the trademark is. Just the same as someone
can write an article about Windows and Microsoft, or a software product
can claim that it runs under Windows or MacOS.
He's allowed to say "This tool allows you to access a BitKeeper
repository".
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
He's not allowed to say "BitBucket is a GPL-ed clone of BitKeeper"
because that implies that BitBucket does what BitKeeper does and nothing
could be farther from the truth.
How about we not turn this into a debate? I politely requested that
people not confuse the world into thinking Product A is the same as
Product B, that's all I requested, it's a reasonable request, we don't
need to debate it. If you feel the need to do so, go for it, but do so
knowing that my silence in no way means that I agree or disagree with you.
On Sat, Mar 01, 2003 at 11:02:22AM -0500, Ben Collins wrote:
> On Sat, Mar 01, 2003 at 07:28:20AM -0800, Larry McVoy wrote:
> > BitKeeper is a trademark, please don't use the BitKeeper name when
> > describing BitBucket. Thanks.
>
> I think he's allowed to use the name so long as he only uses it to
> describe what the purpose of the tool is and recognizes in the same
> document who the holder of the trademark is. Just the same as someone
> can write an article about Windows and Microsoft, or a software product
> can claim that it runs under Windows or MacOS.
>
>
> He's allowed to say "This tool allows you to access a BitKeeper
> repository".
>
>
>
> --
> Debian - http://www.debian.org/
> Linux 1394 - http://www.linux1394.org/
> Subversion - http://subversion.tigris.org/
> Deqo - http://www.deqo.com/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 2003-03-01 at 16:11, Larry McVoy wrote:
> He's not allowed to say "BitBucket is a GPL-ed clone of BitKeeper"
> because that implies that BitBucket does what BitKeeper does and nothing
> could be farther from the truth.
Something is wrong, I agree with Larry.
He should instead say "A tool for accessing bitkeeper repositories" or
"bitbucket compatible proprietary tools are available from .. " ;)
On Sat, Mar 01, 2003 at 05:30:42PM +0000, Alan Cox wrote:
> On Sat, 2003-03-01 at 16:11, Larry McVoy wrote:
> > He's not allowed to say "BitBucket is a GPL-ed clone of BitKeeper"
> > because that implies that BitBucket does what BitKeeper does and nothing
> > could be farther from the truth.
>
> Something is wrong, I agree with Larry.
>
> He should instead say "A tool for accessing bitkeeper repositories" or
> "bitbucket compatible proprietary tools are available from .. " ;)
I can agree with that. At first though, he said not to use the name at
all, without regard to wording.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
> Something is wrong, I agree with Larry.
Errr, it's the first of March today, not the first of April.
John.
On Wed, Feb 26, 2003 at 09:02:12PM +0100, Pavel Machek wrote:
> It is available at http://www.sf.net/projects/bitbucket (no tar balls,
> just get it fresh from CVS).
It would be better if you stored it in BitKeeper just to piss Larry
off.
In article <[email protected]> you wrote:
> It would be better if you stored it in BitKeeper just to piss Larry
> off.
that would be a license violation :)
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
From: Pavel Machek <[email protected]>
Date: Wed, 26 Feb 2003 21:02:12 +0100
Pavel,
> I've created little project for read-only (for now ;-) kitbeeper
> clone. It is available at http://www.sf.net/projects/bitbucket (no tar balls,
> just get it fresh from CVS).
I think that it is waste of your valuable time to create clones of
proprietary software like KitBeeper (I do not want to infringe on Larry's
trademark) is. It is not worth the effort and in fact your work supports
using that proprietary tool. I suggest to completely remove the project.
--
Pavel Jan?k
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
On Sat, Mar 01, 2003 at 07:05:35PM +0100, Pavel Jan?k wrote:
> I think that it is waste of your valuable time to create clones of
> proprietary software like KitBeeper (I do not want to infringe on Larry's
> trademark) is. It is not worth the effort and in fact your work supports
> using that proprietary tool. I suggest to completely remove the project.
I totally agree. We should stop developing Linux now and remove all source
code from kernel.org because it's reimplementation and further development
of the APIs of the propritary "UNIX" operating system is just a waste of
time.
On Sat, 2003-03-01 at 12:05, Pavel Janík wrote:
> ...software like KitBeeper (I do not want to
> infringe on Larry's trademark)...
That's certainly less rude than ButtCreeper :-)
(Sorry, I'll shut the Hell up now)
--
Paul Fulghum [email protected]
Microgate Corporation http://www.microgate.com
From: Christoph Hellwig <[email protected]>
Date: Sat, 1 Mar 2003 18:39:29 +0000
> I totally agree. We should stop developing Linux now and remove all
> source code from kernel.org because it's reimplementation and further
> development of the APIs of the propritary "UNIX" operating system is
> just a waste of time.
You misunderstood my reply. We do have many source control management
software around. Instead of developing something to be able to work with
proprietary systems, we should concentrate on adding missing pieces to
existing software and trying to convince people to not use proprietary
systems because of their freedom. E.g. Linus and other people exercising
"free" KitBeeper license now can not develop SCM software even if they want
to. I think this is really bad for their freedom.
And what will be the next thing?
--
Pavel Jan?k
I wouldn't like to have something like fetchmail for the kernel
configuration.
-- Martin Dalecki in LKML about CML2
At 02:58 PM 3/1/2003 -0600, Paul Fulghum wrote:
>On Sat, 2003-03-01 at 12:05, Pavel Janík wrote:
> > ...software like KitBeeper (I do not want to
> > infringe on Larry's trademark)...
>
>That's certainly less rude than ButtCreeper :-)
>(Sorry, I'll shut the Hell up now)
Hey, that was pretty good. Maybe a bit of humor will help keep folks from
getting excited (again) and ranting all over my mailbox (again and again...)
<peek> darn ;-)
-Mike
On Wed, Feb 26, 2003 at 09:02:12PM +0100, Pavel Machek wrote:
> Hi!
>
> I've created little project for read-only (for now ;-) bitkeeper
> clone. It is available at http://www.sf.net/projects/bitbucket (no tar balls,
> just get it fresh from CVS).
In case it may be of some help, here's a script that is the result of my
own reverse engineering of the bitkeeper SCCS files. It can output a
diff, almost exactly the same as BitKeeper's gnupatch output from a
BitKeeper repo.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
On Sun, Mar 02, 2003 at 12:04:20AM -0500, Ben Collins wrote:
> On Wed, Feb 26, 2003 at 09:02:12PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > I've created little project for read-only (for now ;-) bitkeeper
> > clone. It is available at http://www.sf.net/projects/bitbucket (no tar balls,
> > just get it fresh from CVS).
>
> In case it may be of some help, here's a script that is the result of my
> own reverse engineering of the bitkeeper SCCS files. It can output a
> diff, almost exactly the same as BitKeeper's gnupatch output from a
> BitKeeper repo.
Might aswell supply my hacked sccsdiff script aswell.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
On Sat, Mar 01, 2003 at 11:43:23PM +0100, Pavel Jan?k wrote:
> You misunderstood my reply. We do have many source control management
> software around. Instead of developing something to be able to work with
> proprietary systems, we should concentrate on adding missing pieces to
> existing software
Well, that's the same argument as we don't need UNIX we have DOS.
But anyway, don't you think Pavel is free to develop whatever free software
he likes to develop instead of following you political agenda?
On Sun, Mar 02, 2003 at 09:30:00AM +0000, John Bradford wrote:
> > But anyway, don't you think Pavel is free to develop whatever free
> > software he likes to develop instead of following you political
> > agenda?
>
> What is the goal of the BitBucket project, though?
>
> To develop a version control system, or to annoy Larry?
Given the annoucement probably access the kernel BK tree in real time.
> Why doesn't somebody start working on a dedicated kernel version
> control system?
It's called BitKeeper :)
From: Christoph Hellwig <[email protected]>
Date: Sun, 2 Mar 2003 09:11:30 +0000
> But anyway, don't you think Pavel is free to develop whatever free software
> he likes to develop instead of following you political agenda?
Of course he is - it is one of his freedom. I only wanted to show him that
there are (IMO) better ways to spend his time. And it is no about
politics...
--
Pavel Jan?k
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
-- Rik van Riel in linux-kernel
> BitKeeper is a trademark, please don't use the BitKeeper name when
> describing BitBucket. Thanks.
Sorry, I should have been more carefull about wording. Sourceforge
page states that
Goal of this project is to create version managment system compatible
with BitKeeper.
I hope that's okay with you.
Pavel
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
Hi!
> > I've created little project for read-only (for now ;-) kitbeeper
> > clone. It is available at http://www.sf.net/projects/bitbucket (no tar balls,
> > just get it fresh from CVS).
>
> I think that it is waste of your valuable time to create clones of
> proprietary software like KitBeeper (I do not want to infringe on Larry's
> trademark) is. It is not worth the effort and in fact your work supports
> using that proprietary tool. I suggest to completely remove the
> project.
Actually bk's on-disk format is quite reasonable, and there's a *lot*
of example data in that format, so it might be easier to develop
free version control system this way.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Hi!
> > > I've created little project for read-only (for now ;-) bitkeeper
> > > clone. It is available at http://www.sf.net/projects/bitbucket (no tar balls,
> > > just get it fresh from CVS).
> >
> > In case it may be of some help, here's a script that is the result of my
> > own reverse engineering of the bitkeeper SCCS files. It can output a
> > diff, almost exactly the same as BitKeeper's gnupatch output from a
> > BitKeeper repo.
>
> Might aswell supply my hacked sccsdiff script aswell.
There's a problem with this: it changes CSSC, and its GNU (read: needs
copyright assignment to apply changes). I can't really push your
changes to CSSC :-(. [What I can do is add .diff file into
bitbucket...]
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Mon, Mar 03, 2003 at 12:53:18AM +0100, Pavel Machek wrote:
> Hi!
>
> > > > I've created little project for read-only (for now ;-) bitkeeper
> > > > clone. It is available at http://www.sf.net/projects/bitbucket (no tar balls,
> > > > just get it fresh from CVS).
> > >
> > > In case it may be of some help, here's a script that is the result of my
> > > own reverse engineering of the bitkeeper SCCS files. It can output a
> > > diff, almost exactly the same as BitKeeper's gnupatch output from a
> > > BitKeeper repo.
> >
> > Might aswell supply my hacked sccsdiff script aswell.
>
> There's a problem with this: it changes CSSC, and its GNU (read: needs
> copyright assignment to apply changes). I can't really push your
> changes to CSSC :-(. [What I can do is add .diff file into
> bitbucket...]
I'm putting my changes to CSSC into the public domain. The FSF can do
whatever it wants.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
> But anyway, don't you think Pavel is free to develop whatever free
> software he likes to develop instead of following you political
> agenda?
What is the goal of the BitBucket project, though?
To develop a version control system, or to annoy Larry?
I haven't seen a single post to the list saying, "If we were designing
a version control system dedicated to the Linux kernel, what would you
like to see in it?". Before I started work on my bug database, I
spent a week or so discussing it on the list with people.
Why doesn't somebody start working on a dedicated kernel version
control system?
John.
Hi!
> > But anyway, don't you think Pavel is free to develop whatever free
> > software he likes to develop instead of following you political
> > agenda?
>
> What is the goal of the BitBucket project, though?
>
> To develop a version control system, or to annoy Larry?
To be able to access kernel version history without touching
bk. Annoying Larry is just a side effect, altrough I agree selection
of project name was "interesting" ;-).
> I haven't seen a single post to the list saying, "If we were designing
> a version control system dedicated to the Linux kernel, what would you
> like to see in it?". Before I started work on my bug database, I
> spent a week or so discussing it on the list with people.
Apparently Linus, DaveM and Larry did just this, 2 years ago and
offline. bk is result of that discussion.
> Why doesn't somebody start working on a dedicated kernel version
> control system?
That's way harder than accessing kernel version history. I do not have
time for *that*.
Pavel
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
On Sun, 2003-03-02 at 09:30, John Bradford wrote:
> I haven't seen a single post to the list saying, "If we were designing
> a version control system dedicated to the Linux kernel, what would you
> like to see in it?". Before I started work on my bug database, I
> spent a week or so discussing it on the list with people.
Larry spent a lot of time talking to people directly about such things.
> > I haven't seen a single post to the list saying, "If we were designing
> > a version control system dedicated to the Linux kernel, what would you
> > like to see in it?". Before I started work on my bug database, I
> > spent a week or so discussing it on the list with people.
>
> Larry spent a lot of time talking to people directly about such things.
I meant in relation to Bit Bucket.
If the need for Bit Keeper to make a profit for Bit Mover excludes
Linux developers from using it, the most logical thing to do in my
opinion is to start from scratch and write a version control system
dedicated to furthering Linux kernel development.
Compatibility with Bit Keeper should not be a goal of that project.
John.
On Mon, 3 Mar 2003, John Bradford wrote:
> > > I haven't seen a single post to the list saying, "If we were designing
> > > a version control system dedicated to the Linux kernel, what would you
> > > like to see in it?". Before I started work on my bug database, I
> > > spent a week or so discussing it on the list with people.
> >
> > Larry spent a lot of time talking to people directly about such things.
>
> I meant in relation to Bit Bucket.
>
> If the need for Bit Keeper to make a profit for Bit Mover excludes
> Linux developers from using it, the most logical thing to do in my
> opinion is to start from scratch and write a version control system
> dedicated to furthering Linux kernel development.
>
> Compatibility with Bit Keeper should not be a goal of that project.
^^^^^^^^^^^^^^^^^^^^
>
> John.
Hmmm. Compatibility with existing things is always one of the
considerations of any new product (or project). If compatibility
can be achieved without a significant trade-off in performance,
then it should become one of the goals.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
John Bradford <[email protected]> wrote:
> >
> > Larry spent a lot of time talking to people directly about such things.
>
> I meant in relation to Bit Bucket.
>
> If the need for Bit Keeper to make a profit for Bit Mover excludes
> Linux developers from using it, the most logical thing to do in my
> opinion is to start from scratch and write a version control system
> dedicated to furthering Linux kernel development.
>
> Compatibility with Bit Keeper should not be a goal of that project.
Larry did a pretty good job of determining what the software needed to do to
be useful for the linux-kernel project. Any possible replacement that doesn't
do at least what bitkeeper does is likely dead before it starts.
(nevermind that no replacement is necessary, due to Larry's gratis provision
of the tool to kernel developers...)
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[email protected]>
GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
-----------------------------------------------------------------------
> > > > I haven't seen a single post to the list saying, "If we were designing
> > > > a version control system dedicated to the Linux kernel, what would you
> > > > like to see in it?". Before I started work on my bug database, I
> > > > spent a week or so discussing it on the list with people.
> > >
> > > Larry spent a lot of time talking to people directly about such things.
> >
> > I meant in relation to Bit Bucket.
> >
> > If the need for Bit Keeper to make a profit for Bit Mover excludes
> > Linux developers from using it, the most logical thing to do in my
> > opinion is to start from scratch and write a version control system
> > dedicated to furthering Linux kernel development.
> >
> > Compatibility with Bit Keeper should not be a goal of that project.
> ^^^^^^^^^^^^^^^^^^^^
> Hmmm. Compatibility with existing things is always one of the
> considerations of any new product (or project).
I did consider it, I just don't think it's a good idea.
> If compatibility can be achieved without a significant trade-off in
> performance, then it should become one of the goals.
Agreed, but in a project to develop the best possible version control
system for the Linux kernel [1], I don't see how compatibility with
any other version control system is of any interest at all.
It's only if you want to use several version control systems in
parallel that it might be an issue, but if a single, free, version
control system is in use, I don't see why that would be necessary.
Getting the data out of Bit Keeper and in to a different version
control system is a one-time job, and as far as I am aware there is
no difficulty getting data out of a Bit Keeper repository, (using Bit
Keeper itself), in a suitable format.
[1] As distinct from projects to develop the best possible version
control system in general or to develop a GPLed project to complete
with Bit Keeper.
John.
Hi!
> It's only if you want to use several version control systems in
> parallel that it might be an issue, but if a single, free, version
> control system is in use, I don't see why that would be necessary.
But you *will* be using bitkeeper along with something else, because
linus is not going to switch unless that something else is well
tested, creating chicken-egg problem.
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
> > It's only if you want to use several version control systems in
> > parallel that it might be an issue, but if a single, free, version
> > control system is in use, I don't see why that would be necessary.
>
> But you *will* be using bitkeeper along with something else, because
> linus is not going to switch unless that something else is well
> tested, creating chicken-egg problem.
Well, you could try convincing Alan to use it for the -ac trees, or
the 2.2 kernel to get it tested with a real dataset.
John.
the big reason for haveing it be compatable with existing systems is so
that if people move to it and decide they don't like it they can move away
from it again.
you may like to think that your program is so good that people will never
want to move away, but if it isn't an option then people will be very slow
to adopt it as the risk to their source history just went up a few
notches.
David Lang
On Mon, 3 Mar 2003, John Bradford wrote:
> Date: Mon, 3 Mar 2003 15:08:15 +0000 (GMT)
> From: John Bradford <[email protected]>
> To: [email protected]
> Cc: [email protected], [email protected], [email protected], [email protected],
> [email protected]
> Subject: Re: BitBucket: GPL-ed KitBeeper clone
>
> > > > > I haven't seen a single post to the list saying, "If we were designing
> > > > > a version control system dedicated to the Linux kernel, what would you
> > > > > like to see in it?". Before I started work on my bug database, I
> > > > > spent a week or so discussing it on the list with people.
> > > >
> > > > Larry spent a lot of time talking to people directly about such things.
> > >
> > > I meant in relation to Bit Bucket.
> > >
> > > If the need for Bit Keeper to make a profit for Bit Mover excludes
> > > Linux developers from using it, the most logical thing to do in my
> > > opinion is to start from scratch and write a version control system
> > > dedicated to furthering Linux kernel development.
> > >
> > > Compatibility with Bit Keeper should not be a goal of that project.
> > ^^^^^^^^^^^^^^^^^^^^
> > Hmmm. Compatibility with existing things is always one of the
> > considerations of any new product (or project).
>
> I did consider it, I just don't think it's a good idea.
>
> > If compatibility can be achieved without a significant trade-off in
> > performance, then it should become one of the goals.
>
> Agreed, but in a project to develop the best possible version control
> system for the Linux kernel [1], I don't see how compatibility with
> any other version control system is of any interest at all.
>
> It's only if you want to use several version control systems in
> parallel that it might be an issue, but if a single, free, version
> control system is in use, I don't see why that would be necessary.
>
> Getting the data out of Bit Keeper and in to a different version
> control system is a one-time job, and as far as I am aware there is
> no difficulty getting data out of a Bit Keeper repository, (using Bit
> Keeper itself), in a suitable format.
>
> [1] As distinct from projects to develop the best possible version
> control system in general or to develop a GPLed project to complete
> with Bit Keeper.
>
> John.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>