[darcs-users] [OT] Larry McVoy on the Bitkeeper licence

[David Roundy]

On Wed, Feb 16, 2005 at 09:45:05AM +0100, Karel Gardas wrote:
> On Tue, 15 Feb 2005, Tupshin Harper wrote:
> > John Meacham wrote:
> > >I am curious if anyone has asked Larry whether he would mine a
> > >darcs-bitkeeper interoperability tool being written. If asked publicly
> > >in the right way, mentioning that it would be bi-directional to support
> > >syncing both ways I think he might allow it. Basically, there is no way
> > >he could deny such a tool unless he thought people would use it to
> > >migrate from BK to darcs (rather than the other-way round) hence
> > >publicly admitting that he thinks darcs is better. He might try to say
> > >'sorry, that is forbidden by the license' but he has said
> > >that he intends to selectivly enforce the license, a public appeal might
> > >convince him (or at least force him to be a bit more clear on what
> > >is/isn't allowed) to allow just this tool.

I've asked him privately, and yes, he would mind a darcs-bitkeeper
interoperability tool.  It's possible that public pressure would change is
mind, but it seems highly unlikely, given his past behavior.

I've considered writing a bk-darcs converter that would use BK, just based
on BK documentation, and then making that available and asking Larry if it
could be legally run, or if just converting the repository out of BK would
count as contributing to darcs.  But I'm too lazy.  I imagine it wouldn't
take more than a week or two to hack together a perl script to do it,
provided one didn't worry about efficiency (create a clean copy of each
tree), and one didn't worry about retaining file and directory renames.

Basically you'd need bk commands to ask for a given changeset what the
parents are (I think there can probably only be either one or two parents),
and of course for the metadata.  Every bk revision would be tagged in the
darcs repository.  So you once you have the two parents, you run darcs get
to grab one of them, and darcs pull to get the other, and then you run a bk
command to get the contents of the repository after the changeset, and run
darcs record and tag.  And then pull into the main darcs repository.  It'd
be awfully slow, but could be optimized for non-merge changesets (ones with
only one parent).

> > His idea of interoperability is cvs. Anything like arch or darcs, he
> > considers competition, and since any lossless interaction between the
> > two would necessarily contain "bitkeeper proprietary information" (the
> > dependency information), he would not support such an endeavor.
> > Obviously, this is my conjecture since I haven't had this exact
> > conversation with him. But based on my public and private discussion
> > with him, I would be very surprised if you got any other answer.
> 
> I've read your emails about BK here, and since I'm just beginner, I still
> don't understand your intention or needs to have full graph of version
> available from BK. IMHO we just need _one_ line of development and that's
> exactly what Linus pushes to his public BK repo. Am I wrong?

You need the full graph if you want to keep all the changeset information
that BK has.  The bkcvs repository has fewer than half as many changesets
as the bk repository, simply because it only tries to track one line of
development.  You can get a patch for each changeset from bkbits, but
there's no way to figure out to which version of the repository that patch
should be applied.

Bad ASCII graphics for a history of a given file

   C2->C3
  /      \
A1--------->A2
  \      /
   B2->B3

Here we have a total of five changesets, but if the "A" track is Linus,
then his history only has two versions of this file.  Instead, we could
follow either B's history or C's history, which would give us more
granularity (and this as I understand it is what bkcvs tries to do), but
you'd still be missing changesets.

With darcs' patch commutation formalism, we *can* represent all these
changes as a single sequence of patches without losing information (except
for the history information, which we could retain if we tagged each
version).  But to do the conversion right (without dropping changesets as
irrelevant), we really need the full graph of the history.
-- 
David Roundy
http://www.darcs.net