Re: BitBucket: GPL-ed *notrademarkhere* clone

[Jeff Garzik]

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