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.

Comments

As Tridge says in the README

[Anonymous Coward]

Finally, I would like to point out the obvious fact that Linus was perfectly within his rights to choose bk for the kernel. I personally would not have chosen it, but it was his choice to make, not anyone elses. Linus is now in the unenviable position of changing source code management systems, which is a painful task, particularly when moving away from a system that worked as well as bk did. If you want to help, then help with code not commentary. There have been enough flames over this issue already.

so let's keep it civil, eh?

Re:As Tridge says in the README

[snorklewacker]

> If you want to help, then help with code not commentary

Fact is, this is slashdot. It's the nee plus ultra of peanut galleries. Note well that Linus doesn't read or post to slashdot -- he's been busy working on git, which is not a great SCM itself, but it's turning out to be pretty hot as a library. Arch is adopting git as a backend, and darcs is talking about using libgit (once there is a libgit) for a performance boost.

Re:Why not GNU Arch?

[grumbel]

### I must say I haven't used it, but from reviews and comparisons I've read, it seems to be a good tool.

Well, try to use it then. The feature that it has indeed sound nice in theory, but Arch has huge problems when it comes to usability and performance, which make it unusable for something as large as Linux and unconfortable for most other projects around. A simple look at the 'help' already makes that pretty clear that there is something wrong with the userinterface:

$ svn help | wc -l
41
$ tla help | wc -l
186

Its however not a lost case, Bazaar-ng is trying to fix those problems of Arch:

* http://bazaar-ng.org/

Re:Might come in handy now

[LiENUS]

Just a note, this tool assists in no way with the move away from bitkeeper, it was only of benefit when the linux kernel was still in bitkeeper. All this lets you do is pull source from a bitkeeper server, it does not replace the bitkeeper server. The way this benefits the open source community is now developers can begin intregrating this library into other development systems (like IDEs) and allowing bitkeeper integration.

Re:Why not GNU Arch?

[cduffy]

Arch is quite scalable, if used correctly -- and the remaining places where it aren't are either (1) implementation rather than design issues, or (2) issues which have a solution proposed which nobody's bothered to implement yet.

Folks who actually do their setup correctly (greedy, non-sparse revlibs; hardlink trees; reiserfs) have reported some very, very impressive benchmarks - and the remaining scalability issues mostly relate to patch log management, and there've been plenty of solutions proposed and on the table that could be implemented very, very quickly if anyone was feeling enough pain to prioritize them (or hire Tom to prioritize them -- same thing, really).

Re:Waste of time

[Bananenrepublik]

Tridge's tool is about extracting the complete history out of a bitkeeper server, bitkeeper's open client is about providing an equivalent to cvs up. Fairly obvious if you RTFA and TFPYLT (the f*cking page you're linking to).