Slashdot Mirror


Tridge Releases BitKeeper-Compatible Tool

Peter Willis writes "Looking at Freshmeat today (a part of OSTG) it seems Andrew Tridgell has released the BitKeeper-compatible source code management client mentioned on slashdot recently, called SourcePuller. As part of the downloads available for the project you can also get dump files which detail how to pull data from BK trees without the use of libsp. From the README: 'SourcePuller is not intended to be a full replacement for BitKeeper. Instead, you should use SourcePuller as an interoperability tool for situations where you cannot use bk itself. SourcePuller is missing a large amount of core functionality from BitKeeper, and thus is not suitable as a full replacement.'" Article available about the release on The Register.

10 of 189 comments (clear)

  1. Might come in handy now by Anonymous Coward · · Score: 5, Interesting

    with the move away from bitkeeper. :-D

    On a serious note, it's good that this apparently oh so evil piece of software is finally out in the open, so that the people can see that all the fuss was about a tool that allows you to get your data that is managed by a propietary tool. How evil...

  2. Re:Why not GNU Arch? by cduffy · · Score: 4, Interesting

    Arch is a good tool -- once you've wrapped your mind around it. Coming from CVS, that's hard.

    One of the problems I'm having at work is that, having wrapped my mind around Arch, I'm for all intends and purposes unable to go back to thinking in CVS primatives -- the conceptual model is that much better. However, since Arch isn't practical for use at my place of employment (no usable win32 port, much less one with a GUI the UI folks can use), I've become damn near useless as SCM advisor -- my mental model just isn't aligned for CVS anymore, and the thought of trying to "fix" that (by retraining myself to work within all of CVS's limitations again) is just too damn horrifying.

    In a year and a half, maybe, or however long it is, Bazaar-NG will be ready for commercial use, and then we'll have somethnig that'll let me have my pretty conceptual model and actually be usable by the rest of staff. It's a dream, anyhow.

  3. Wow, that's a lot of code for telnet poking around by Chyeburashka · · Score: 3, Interesting
    zoopark:~/sp-0.1 gena$ cat `find . -name "*.c"` | wc -l
    13416
    zoopark:~/sp-0.1 gena$ cat `find . -name "*.h"` | wc -l
    859
    zoopark:~/sp-0.1 gena$ cat `find . -name "*.[ch]"` | wc -l
    14275
  4. Re:As Tridge says in the README by Anonymous Coward · · Score: 2, Interesting

    You can however refrain from posting and contact someone about helping with the code. It's really not a thing I have time for or even interests me, so I doubt I'll be much help. I'm mostly a measly web/database programmer anyway. :)

    -- gid

  5. Re:Why not GNU Arch? by cduffy · · Score: 2, Interesting

    Oh, it's not that bad. Yes, Tom has given Arch features which are tied to how he works -- but none come to mind that actually stop you from working a different way, as opposed to merely being annoying.

    That said, I'm anxiously awaiting Bazaar-NG.

  6. Re:Wow, that's a lot of code for telnet poking aro by HeelToe · · Score: 1, Interesting
    Why not just:
    wc -l `find . -name "*.[ch]"`
  7. This is what Larry was complaining about? by X.25 · · Score: 4, Interesting

    If *this* is the project Larry was complaining about so much, I can't wait to hear what he has to say now.

    Larry, is THIS the reverse engineering you were talking about? Stealing your ideas? Making OSS version of BitKeeper? Blah, blah.

    There were so many cases of people making opensource software talking to proprietary back-end (getting stock quotes with tool via TCP, for example, instead of using Java/Windows clients), and noone really made so much noise.

    I have no respect anymore for BitKeeper and Larry if this is all Tridge was "reverse engineering".

  8. Re:Why not GNU Arch? by krmt · · Score: 3, Interesting

    I tried using arch to manage my debian packages, which have an upstreamversion-packageversion versioning number scheme. Both tla and baz complained that this wasn't an appropriate version number. This is beyond annoying, it makes arch unusable for my fairly simple needs.

    Plus, the UI is completely tied to the implementation, so you have to know a ton about the underpinnings of arch in order to use tla. I don't want to know how arch does what it does. I don't care.

    The baz people are working on fixing this, but there's a lot of problems to be fixed (see this for the massive list) and I think it'll take them some time to do so. Currently, baz is pretty buggy for me too, segfaulting on things like branching. That said, I have a lot of faith in both the baz team and Martin Pool, simply because they've thought things through very well. Currently though, tla and baz are nothing but an exercise in pain for me to use, and bzr isn't ready yet. I'll keep checking on them, because I really want to like them, but they make it so hard on me.

    --

    "I may not have morals, but I have standards."

  9. Waste of time by bheading · · Score: 2, Interesting

    But there's already an open-source tool for pulling code out of BitKeeper. So what is the point in Tridge's release?

    1. Re:Waste of time by Quixote · · Score: 3, Interesting
      Look at the date: 2005/03/17 (or March 17th 2005 for the rest of you). Obviously it was released to undercut Tridge.

      Tridge had 2 options after that:
      a) release his version (which is also just a client) and get the "is this it? But why did Tridge do that?" comments like the parent; or
      b) not release it, and let the rumors fly around.

      I'm glad Tridge chose to release his version and now we can all move on. Of course, the real loser in this is McVoy (he lost his biggest mouthpiece), followed by Linus (who has to now duplicate the functionality of BK as much as he can, and while he's mucking with the tools the kernel development takes a backseat).