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

[kfg]

so let's keep it civil, eh?

Oh! Civility. I'm afraid we don't have much call for that around these parts. May I interest you in some irony?

KFG

Re:As Tridge says in the README

[qortra]

Nice quote, but the thing is, that's all we CAN do here. Slashdot is not a place to do software development; it isn't set up for that. It's a place for discussion. So basically, discuss, praise the author, try & review the software, but if you want to "help with code", you're in the wrong place.

Re:As Tridge says in the README

[Elwood P Dowd]

You heard it hear first, Tridge is anti-comments. If you want GCC to continue to support comments, speak up now or forever hold your peace.

Re:As Tridge says in the README

[FidelCatsro]

Irony always goes astray here , Perhaps i could intrest you in some apathy.

Re:As Tridge says in the README

[0x461FAB0BD7D2]

From the source code I've seen and debugged, it seems most programmers are anti-comments.

Re:As Tridge says in the README

[Elwood P Dowd]

"heard it hear first"

Jesus God, that's one of the dumbest fuckups I've seen in a /. comment, and it's in my comment.

Re:As Tridge says in the README

[Anonymous Coward]

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

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:As Tridge says in the README

[SnowZero]

Sometimes I am anti-comment. When I get some example code that has 10+ lines of comments per line of actual code, I usually delete most of the comments so I can see what the heck the code is actually doing. There is such a thing as too much verbosity, or at the very least, some documentation shouldn't be in the middle of the function.

Re:As Tridge says in the README

[indifferent children]

it seems most programmers are anti-comments

You're kidding right? What do you call all of that whitespace that we sprinkle around our code? Those are comments.

If a block of code is especially self-contained or tricky, then it is surrounded by two carriage-returns before the block and two carriage-returns after the block.

If some statements are part of a loop, then we gratuitously indent them. That's not for the compiler's benefit; those are comments.

Don't even get me started on our extreme generosity in supplying names (not just types!) in our function and method prototypes. What, you want us to draw you a map?



BTW, I would submit more Insightful comments in my code if only my peers with good karma had Mod Points at code review time.

Re:As Tridge says in the README

[jhantin]

"Ewe herd it here first"

Oh. That's just baaaaad.

Time to get back on topic, that's enough subversion of this thread.

Re:As Tridge says in the README

[0x461FAB0BD7D2]

At least you don't get your code-reviewers moderating your code as -1,Redundant and -1,Offtopic. That's almost mean-spirited enough to make me stop submitting "Hello, World" patches.

But I shall persevere. And perhaps, I'll add some CRLFs this time.

Re:As Tridge says in the README

[Foosinho]

Two "+5 Funny" out of the same post? I bow down to your slash-skills.

Re:As Tridge says in the README

[einhverfr]

Wow.... I have to say... I wish all programmers commented the way you do.

What I personally hate is the way many programmers often try to tell me how their code works using comments. These are dangerous. Whitespace provides hints as to how to read how it works, but the code has to be your authoritative point for that: SPOT principle at work (comments should not get outdated).

If the code does not speak for itself, it is bad code and should be rewritten.

Now........ When you do comment... Don't tell me HOW your code works! However, it is perfectly reasonable to tell me why you make a specific decision. For example: "Sorry, this code is ugly. However, I can't come up with a better answer at the moment." or "This code here is to prevent an SQL-Injection attack." Or even "As per RFC. Sorry folks, FTP to Mars won't work."

Might come in handy now

[Anonymous Coward]

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...

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:Might come in handy now

[4of12]

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.

In a way it's good to have issues like this bubble up to give people a chance to really think about the fundamental principles involved in open source development.

For instance, it would be hypocritical to applaud Tridge for his work on reverse-engineering SMB to create Samba and to simultaneously criticize him for doing the exact same thing with BK.

Likewise, to criticize MS for using secrecy to make money with its products, while decrying the effect Tridge's reverse engineering has on the income of the Larry trying to feed his family by selling BK.

The principles have to hold independent of the emotional circumstances and the players of the game.

FOSS is all about the natural migration of more and more software technology into commodities. And that will inevitably be a difficult pill to swallow for anyone who has created new software that makes money for them. At some point, if the software is really useful, other competent programmers will look to produce a work-alike functionality. And it will be for the greater good of humanity as a whole because they will be able to use better tools for less money. Even as it erodes the financial benefits that accrue to one or to a few from having thought and done it first.

A happy ending would be Tridge's sofware encouraging more people to buy the BK core to interoperate with Sourcepuller. But, in the longer run, I expect a free core will eventually be developed and it will displace the proprietary one.

Re:Might come in handy now

[SlashDread]

"The principles have to hold independent of the emotional circumstances and the players of the game." Spoke the high morale philosofer. Back in the real world, we behave, and make laws accordingly, that are big fat principle breakers, for perfectly valid practical reasons. We can fly a flag. We cannot fly the Nazi flag. Beng. Principle violation. We can speak. We cannot speak hate propaganda. Beng. Murder bad, war good. Beng beng. The principles dont differ, the practical consequenses differ. From some flag we yell and screech. From some plane crash we war. From some hate propaganda we revolutionize. People do the same on every level, we find 10 bucks, we keep it, we find 100 bucks, we go to the police. We will see who is right; if BK goes bankrupt, it was Linus.

Like Grains of Sand in an Hourglass...

[jeff_schiller]

...so goes the soap opera that has become the Linux community

Re:Like Grains of Sand in an Hourglass...

[indifferent children]

Suggested names:

All My Children (a forking-good name)

As the Hello World Turns

One File to Give

General Protection

The <B> and the Beautiful

Re:Why not GNU Arch?

[space_dude_27]

Perhaps because Tridge never set out to create a replacement for BK - merely a tool that would interoperate with it and enable you to get source out of a BK repository without actually running the BK client.

Re:Why not GNU Arch?

[sfraggle]

I must say I haven't used it

Come back when you've tried to read the documentation - you'll quickly see why nobody in their right mind is considering GNU Arch.

Logo?

[Anonymous Coward]

A big huge middle finger!

Re:Why not GNU Arch?

[0x461FAB0BD7D2]

Flywheels has a history of linking articles at his site, PressEsc to un-related stories and comments, in order to boost his PageRank.

He has even linked to Google to redirect to his page so that he escapes detection from mods.

Feel free to check his history.

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:Why not GNU Arch?

[Anonymous Coward]

Nobody...
Yes, you are the very very very very first first first person to come up with something THAT original.

Re:Why not GNU Arch?

[cduffy]

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.

No thanks

[A nonymous Coward]

Not today, thank you. Perhaps you could come around tomorrow, or maybe the day after? I'll check my calendar, but later, ok?

Re:No thanks

[babyrat]

tomorow is bad for me - I plan to stop procrastinating then.

Wow, that's a lot of code for telnet poking around

[Chyeburashka]

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

Re:Why not GNU Arch?

[keesh]

I don't want a tool that tries to tell me how to do things. I want a tool that stays the hell out of my way and lets me do some work. Their "way things should be" is not suitable for all software development models, yet their tool is so closely tied to said model that they actively add in features to try to stop you from working any other way.

WTG

[Tharkban]

Congratulations to Tridge.

Sounds like everyone was within their rights. Which means disagreement is simply the by product of everyone being human.

Why the P.C name?

[thehunger]

A tool that lets you Pull stuff out of BitKeeper. How did he manage to avoid naming it BitPull?

Re:Why the P.C name?

[williw]

As soon as I read your comment, I immediately thought he should have call it PitBull or KeepBitter (get it... reverse engineering reverse name, unintended consequences. har har har)

Re:Why not GNU Arch?

[spworley]

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

And with the support of the community, and a lot of developer work, they'll be able to reduce Arch's 'help' text down to only 10 words, making it the most powerful source control system.

Re:Why not GNU Arch?

[cduffy]

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.

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).

This is what Larry was complaining about?

[X.25]

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".

Re:This is what Larry was complaining about?

[MattW]

And what the hell was Linus talking about? He can understand not wanting someone "riding on their coattails, solve the problem yourself" - what problem? A tool for pulling snapshots? This is not the vast mysteries of SCM being solved, this is a utility.

Re:Why not GNU Arch?

[krmt]

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.

Waste of time

[bheading]

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

Re:Waste of time

[Quixote]

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).

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).

Shoulda named it...

[Cyn]

BitTaker

Or, for a more exacting description of what their relationship is... rename both tools:

BitKeeper -> BitPitcher
SourcePuller -> BitCatcher

Re:Wow, that's a lot of code for telnet poking aro

[Chyeburashka]

Excellent point. That is actually necessary with a sizable project, like the kernel.

[gena@zoopark linux-2.6.12-rc3]$ find . -name "*.[chS]" | xargs cat | wc -l
6250930

Wow, that's a lot of code for a project that started out with:

Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers? Are you without a nice project and just dying to cut your teeth on a OS you can try to modify for your needs? Are you finding it frustrating when everything works on minix? No more all- nighters to get a nifty program working? Then this post might be just for you :-)

Re:Probably not

[Master of Transhuman]

Ah, the first idiot posts...

First of all, as I understand it, the commercial license involved says you will not reverse engineer the product YOU licensed. SourcePuller doesn't do that if YOU use it with some other SCM - it simply interoperates. It may do that if Tridge wrote it that way, which he didn't since he wasn't a licensee in the first place.

Secondly, using SourcePuller does not "get you aside from losing a tool". That statement is just idiotic. SourcePuller gets you exactly what Tridge says - interoperability with BK.

If BK is replaced as the dominant SCM, SourcePuller will be obsolete only when no one uses BK at all. When no one uses BK at all because there is something better, what is the problem with "losing a tool"? The statement is nonsense.

As for Samba, does anybody believe Samba would exist in the form it does if Windows didn't exist? And referencing Samba's AD support as being independent of Windows is just laughable. Samba entire existence is due to the need (however temporary) for Windows interoperability.

Some of the posts on /. are just unbelievable...

Used already?

[jefu]

Isn't that Wendy's new Logo?

The original UNIX code

[btarval]

Heh. This reminds me of some of the original UNIX code, from the V6/V7 days.

The startup code was all done in DEC assembly (of course), in a file called locore.s (or something like that - it's been years since I've seen it). Either Brian Kernigham or Dennis Ritchie must have written it; I think it was the former.

Utterly obtuse assembly code, unless perhaps you've spent a good deal of time programming in DEC assembly. Then, no doubt, it was quite clear.

Anyway, about halfway down (after about 50 lines or so), was this priceless comment:
"Here's the tricky part"

Heh. Thanks guys.