Re: RFC - tarball/patch server in BitKeeper

From: Tupshin Harper (tupshin_at_tupshin.com)
Date: 12/15/03

  • Next message: Fruhwirth Clemens: "Cryptoloop (<2.4.22) to Cryptoloop (>2.5.x) Migration Guide" 
    Date:	Sun, 14 Dec 2003 16:19:35 -0800
To: Larry McVoy <lm@bitmover.com>

    Larry McVoy wrote:

    >On Sun, Dec 14, 2003 at 03:17:04PM -0800, Tupshin Harper wrote:
    >
    >
    >>I'm sure many people will find this useful. Personally (and this is not
    >>intended as any sort of flame bait), I just want a way to get access to
    >>all raw bk changesets for a given project.
    >>
    >>
    >
    >I'm sure you do, I've read your postings on various SCM mailing lists.
    >You'll have to get your test data elsewhere, sorry, we're not in the
    >business of helping you develop a competing product. Using BK to do
    >that is a violation of the free use license and I'm sure you are aware
    >of that.
    >
    >
    Of course...that's the only reason why it's an issue.

    >
    >
    >>All existing methods of
    >>getting information out of a bk repository either involve running bk
    >>yourself, or getting incomplete information. You have argued
    >>(succesfully) that the CVS export doesn't lose very much information,
    >>but an argument can be made that any information loss is too much. After
    >>all, the information I am talking about is simply what was put into the
    >>system by the developers in the first place.
    >>
    >>
    >
    >Nonsense! It's the information put in there by BitKeeper. The BK2CVS
    >export is an almost perfect mirror of what you'd get if the developers
    >were using CVS or Subversion or whatever.
    >
    >
    What are are effectively doing, then, is creating vendor lock-in based
    on file format...a very Microsoftian approach. You are encouraging
    developers to adopt your tool, but then telling them that if they ever
    want to adopt a different tool, then they will have to forego using some
    of the information that they created using your tool. So the decision of
    which tool to be used becomes based on pain of switching, and not based
    on technical merit. Hmmm.

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

  • Next message: Fruhwirth Clemens: "Cryptoloop (<2.4.22) to Cryptoloop (>2.5.x) Migration Guide"

    Relevant Pages

    • Re: RFC - tarball/patch server in BitKeeper
      ... I've read your postings on various SCM mailing lists. ... > system by the developers in the first place. ... were using CVS or Subversion or whatever. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: log-buf-len dynamic
      ... > And the reason Andrea hasn't found bitkeeper to be nicer than CVS is he isn't ... > trying to integrate the work of 300 other developers into his personal tree ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Public Access to Perforce?
      ... Exporting to CVS is a bit harder because CVS has ... much larger than the storage for the Perforce version of the same). ... first test for any open source replacement for CVS in the FreeBSD project ... >> collaboration opportunities among developers. ...
      (freebsd-current)
    • Re: Version Control Software
      ... If your developers use PCs to edit and write COBOL, ... including the old warhorse CVS. ... To join/leave the list, search archives, change list settings, * ...
      (comp.sys.hp.mpe)
    • Re: FreeBSD 6.0 and onwards
      ... > I've never proposed to replace CVS with anything else. ... > replace Perforce by GNU Arch. ... It's worth pointing out that it's taken several years for Perforce to get ... Then we should see about whether there are FreeBSD developers who ...
      (freebsd-current)