Re: BitBucket: GPL-ed *notrademarkhere* clone

Jeff Garzik
2003-03-02T20:02:20Z

Andrea Arcangeli wrote:
> your point is purerly theorical at this point in time. bitbucker is so
> far from being an efficient exporter that arguing right now about
> stopping at the exporter or going ahead to clone it completely is a
> totally pointless discussion at this point in time.
>
> Once it will be a fully functional exporter please raise your point
> again, only then it will make sense to discuss your point.

Ok, fair enough ;)

> I'm not even convinced it will become a full exporter if Larry finally
> provides the kernel data via an open protocol stored in an open format
> as he promised us some week ago, go figure how much I can care what it
> will become after it has the readonly capability.

I think this is a fair request.

IMO a good start would be to get BK to export its metadata for each
changeset in XML. Once that is accomplished, (a) nobody gives a damn
about BK file format, and (b) it is easy to set up an automated, public
distribution of XML changesets that can be imported into OpenCM, cvs, or
whatever.

>>Let us get this small point out of the way: I agree that GNU CSSC
>>cannot read the BitKeeper ChangeSet file, which is a file critical for
>>getting the "weave" correct.
>
>
> This is not what I understood from your previous email:
>
> "BK format"? Not really. Patches have been posted (to lkml, even) to
> GNU CSSC which allow it to read SCCS files BK reads and writes.
>
> Since that already exists, a full BitKeeper clone is IMO a bit silly,
>
> now you're saying something completely different, you're saying, "yes the
> CSSC obviously isn't enough and we _only_ _need_ the exporter but please
> don't do more than the exporter or it will waste developement
> resources". This is why you changed topic as far as I'm concerned, but
> no problem, I'm glad we agree the exporter is useful now.

I am sorry for the misunderstanding then. Let me quote from an email I
sent to you yesterday:

A BK exporter is useful.

So I think we do agree :)

>>To me, a "BK clone, read only for now" is vastly different from a "BK
>>exporter". The "for now" clearly implies that it will eventually
>>attempt to be a full SCM.
>
>
> Why do you care that much now? I can't care less. Period. I need the
> exporter and for me the exporter or the bk-clone-read-only is the same
> thing, I don't mind if I've to run `bk` or `exportbk` or rsync or
> whatever to get the data out.
>
> If bitbucket will become much better than bitkeeper 100 years from now,
> much better than a clone, is something I can't care less at this point
> in time, and it may be the best or worst thing it will happen to the
> whole SCM open source arena, you can't know, I can't know, nobody can
> know at this point in time.
>
> You agreed the exporter is useful, so we agree, I don't mind what will
> happen after the useful thing is avaialble, it's the last of my worries,
> and until we reach that point obviously there is no risk to reinvent the
> wheel (unless the data become available in a open protocol first).

Yes. As you see, I care about the future and not the present, in my
arguments: I believe that a BK clone may hurt the overall [future]
effort of creating a good quality open source SCM. So, in my mind I
separate the two topics of "BK exporter" and "future BK clone."

To get back to the topic of "BK exporter", I think it is more productive
to get Larry to export in an open file format. I will work with him
this week to do that. Reading the BK format itself may be interesting
to some, but I would rather have BitMover do the work and export in an
open file format ;-) Reading BK format directly is "chasing a moving
target" in my opinion.

Jeff