Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: BitKeeper – Enterprise-ready version control, now open-source

bitkeeper.org

Post reply on HN
Print view View original

211–220 of 309 posts

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#211

Post by tmd83 »

luckydude wrote: post #134
caf wrote: post #129

Earlier quoted context omitted.

Presumably if you then delete that first line in the third version, you get something like ^AI 1 this is the first line in the first version. ^AE 1 ^AD 3 ^AI 2 this is the line that was added in the second version ^AE 2 ?

Close. By the way there is a bk _scat command (sccs cat, not poop) that dumps the ascii file format so you can try this and see. The delete needs to be an envelope around the insert so you get ^AD 3 ^AI 1 this is the first line in the first version. ^AE 1 ^AE 3 ^AI 2 this is the line that was added in the second version ^AE 2 That whole weave thing is really cool. The only person outside of BK land that got it was Br…

Probably missing something. Both are working on one file at a time and have some form of changeset. One is adding from back to forward (kind of) another is from forward to back (rcs). Not sure where the reduction of work coming from.

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#212

Post by qwertyuiop924 »

luckydude wrote: post #123
bcantrill wrote: post #101

Earlier quoted context omitted.

That is my understanding, yes -- but the NSE and (McVoy-authored) NSElite chapters of the saga pre-date me at Sun. Before my "Fork Yeah!" talk[1][2], from which this is drawn, I confirmed this the best I could, but it was all based only on recollections of the engineers who were there (including Larry). I haven't found anything written down about (for example) NSElite, though I would love to get Larry on the record t…

The NSE was Suns attempt at a grand SCM system and it was miserably slow (single threaded fuse like COW file system implemented in user space). I did performance work back then, sort of a jack of all trades (filesystem, vm system, networking, you name it) so Sun asked me to look at it. I did and recoiled in horror, it wasn't well thought out for performance. My buddies in the kernel group were actually starting to qu…

1 man using perl can outpace 8 on C++. Who would've thought? /sarcasm. But seriously, I think this is one of the classic instances of what is now quite common knowledge about dynamic scripting languages: They let you get things done MUCH faster. I think the tools group learned the wrong lesson from this, but OTOH, who would want to start developing all of their new software in perl? And given that python hadn't caught on yet, there really wasn't much else out there in the field.

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#213

Post by qwertyuiop924 »

nullnix wrote: post #201
luckydude wrote: post #50

Earlier quoted context omitted.

RCS is patch based, the most recent version is kept in clear text and the previous version is stored as a reverse patch and so on back to the first version. So getting the most recent version could be fast (it isn't) but the farther back you go in history the more time it takes. And branches are even worse, you have to patch backwards to the branch point and then forwards to the tip of the branch. SCCS is a "weave".…

I had... much too extensive experience both with SCCS weaves and with hacking them way back in the day; I even wrote something which sounds very like your smoosh, only I called it 'fuse'. However, I wrote 'fuse' as a side-effect of something else, 'fission', which split a shorter history out of an SCCS file by wholesale discarding of irrelevant, er, strands and of the history relating to them. I did this because the…

Huh. Now I wonder how BK resolved this.

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#214

Post by nullnix »

luckydude wrote: post #125
emn13 wrote: post #111

Earlier quoted context omitted.

I think people have a way too high tolerance for this kind of crap. We're also kidding ourselves if we think we're smart enough to work with this kind of complexity at no cost. Our job is often to think up new things. It's really hard to come up with new abstractions when your thinking is muddled by all kinds of incidental complexity.

This is buried but in case anyone reads it, the real reason to open source BK is to show the world that SCM doesn't have to be as error prone or as complicated as Git. You need to understand how Git works to use it properly; BK is more like a car, you just get in and drive.

That metaphor... needs work. Cars need a considerable amount of training to learn to use safely, let alone correctly. I can hack C enough that I dream in it routinely, and due to the resulting brain damage found git intuitive from the start, but there is no way I'll ever learn to drive: it's just too hard.

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#215

Post by Annatar »

rbanffy wrote: post #209
Annatar wrote: post #207

Earlier quoted context omitted.

You again! (:-) You know that the VHDL code for UltraSPARC T1 and T2 has been open sourced? If I had enough knowledge about synthesizing code inside of an FPGA, I would be building my own SPARC-based servers like there is no tomorrow! As long as the code for those processors remains free, and a license to implement a SPARC ISA compliant processor only costs $50, the SPARC will never really, truly be gone, especially…

FPGA is not magic. SPARC implemented on FPGA will never be competitive with consumer-level x86's

I thought that is clear? Apparently not...

FPGA's are cheap and good enough for prototyping; once one has a working VHDL / Verilog code, it's tapeout time.

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#216

Post by nullnix »

qwertyuiop924 wrote: post #213
nullnix wrote: post #201

Earlier quoted context omitted.

I had... much too extensive experience both with SCCS weaves and with hacking them way back in the day; I even wrote something which sounds very like your smoosh, only I called it 'fuse'. However, I wrote 'fuse' as a side-effect of something else, 'fission', which split a shorter history out of an SCCS file by wholesale discarding of irrelevant, er, strands and of the history relating to them. I did this because the…

Huh. Now I wonder how BK resolved this.

Yeah. I suspect the answer is 'store all binary data in BAM', which then uses some different encoding for the binary stuff -- but that then makes my gittish soul wonder why not just use that encoding for everything. (It works for git packfiles... though 'git gc' on large repos is a total memory and CPU hog, one presumes that whatever delta encoding BAM uses is not.)

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#217

Post by marcinkuzminski »

jason_s wrote: post #155
canadiangeek2 wrote: post #136

Earlier quoted context omitted.

My $0.02 canadian; Build something that kicks Gitlab and Github's ass. What an opportunity. Support both BK and GIT repos. Provide a distributed workflow that enterprises will love. Enterprises are obviously where the remaining dollars are. There are billions of dollars of inefficiencies in that sector. Many of these enterprises do NOT want to host their code on Github and are buying Gitlab. Be better than Gitlab.

^^ this. PLEASE. :-( Bitbucket has been rotting since Atlassian bought them, and now there's really no "killer app" for Mercurial hosting. There are Mercurial hosting services out there, but nothing anywhere close to Github/Gitlab.

You should check out RhodeCode. It's no hosting platform, but hosting it yourself is much better. It support Mercurial, and all latest things that comes with it like phases, largefiles etc.

Actually since BK is now opensource we might think of adding a BK backend to RhodeCode and our VCS abstraction layer that already supports GIT, Mercurial and Subversion

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#218

Post by Annatar »

lukaslalinsky wrote: post #190
luckydude wrote: post #87

Earlier quoted context omitted.

bzr got more than that from BK, it got one of my favorite things, per-file checkin comments. I liken those to regression tests, when you start out you don't really value them but over time the value builds up. The fact that Git doesn't have them bugs me to no end. BZR was smart enough to copy that feature and that's why MySQL choose bzr when they left BK. The thing bzr didn't care about, sadly, is performance. An eng…

If I remeber the history correctly, per-file commit messages were actually a feature that was quickly hacked in to get MySQL on board. It did not have that before those MySQL talks and I don't think it was very popular after. Performance indeed killed bzr. Git was good enough and much faster, so people just got used to its weirdness.

> Git was good enough and much faster, so people just got used to its weirdness.

And boy is git weird! In Mercurial, I can mess with the file all day long after scheduling it for a commit, but one can forget that in git: marking a file for addition actually snapshots a file at addition time, and I have read that that is actually considered a feature. It's like I already committed the file, except that I didn't. This is the #1 reason why I haven't migrated from Mercurial to git yet, and now with Bitkeeper free and open source, chances are good I never will have to move to git. W00t!!!

I just do not get it... what exactly does snapshotting a file before a commit buy me?

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#219

Post by justinclift »

luckydude wrote: post #135
justinclift wrote: post #121

Earlier quoted context omitted.

Are you aware of any hosting solutions that support BK as-is? eg something like Gogs or similar Asking due to looking for a Gogs/GitLab (like) server side solution for a project under development. However, it needs to handle binary data well, which Git-based solutions don't.

We've got a very primitive hosting service up at bkbits.net. One of the ways we hope to survive is to evolve that into something closer to Github.

Interesting. Looking for the source of that, is this it?

  http://bkbits.net/u/wscott/bkbits/

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#220

Post by Annatar »

SwellJoe wrote: post #99
qwertyuiop924 wrote: post #97

Earlier quoted context omitted.

Eh. Linux does have a LOT of problems. Well, so does everything, but it's not like it's "great." More like "good." But yeah, it was weird that everybody thought NT was going to be the future. And now, MS has opensourced a good deal of infrastructure, is working with Node, has announced an integrated POSIX environment for Windows. And since it's in corporate, it might even be able to fix the fork(2) performance proble…

Great is a relative term. But, can you name an OS, especially a UNIX, that is better in the general case? By "general case", I mean, good for just about anything, even if there's something better for some niche or role. Also, take into account the world we live in: More computing happens on servers and phones than on desktops and laptops; and judge the OS based on how it's doing in those roles. I sincerely consider L…

> Great is a relative term. But, can you name an OS, especially a UNIX, that is better in the general case? By "general case", I mean, good for just about anything, even if there's something better for some niche or role. Also, take into account the world we live in: More computing happens on servers and phones than on desktops and laptops; and judge the OS based on how it's doing in those roles.

Okay then, SmartOS. Why is an exercise left for the reader, because it would just take too much and too long to list and explain all the things it does better, faster and cheaper than Linux in server space; that's material rife for an entire book.

> can you honestly say you enjoyed working on it more than Linux?

Enjoyed it?!? Love it, I love working with Solaris 10 and SmartOS! It's such a joy not having a broken OS which actually does what it is supposed to do (run fast, be efficient, protect my data, is designed to be correct). When I am forced to work with Linux (which I am, at work, 100% of the time, and I hate it), it feels like I am on an operating system from the past century: ext3 / ext4 (no XFS for us yet, and even that is ancient compared to ZFS!), memory overcommit, data corruption, no backward compatibility, navigating the minefield of GNU libc and userland misfeatures and "enhancements". It's horrible. I hate it.

> The userspace on Solaris was always drastically worse than Linux,

Are you kidding me? System V is great, it's grep -R and tar -z that I hate, because it only works on GNU! Horrid!!!

> But, Linux brought us a UNIX we could realistically use anywhere, and at a price anyone could afford.

You do realize that if you take an illumos derived OS like SmartOS and Linux, and run the same workload on the same cheap intel hardware, SmartOS is usually going to be faster, and if you are virtualizing, more efficient too, because it uses zones, right? Right?

It's like this: when I run SmartOS, it's like I'm gliding around in an ultramodern, powerful, economical mazda6 diesel (the 175 HP / 6 speed Euro sportwagon version); I slam the gas pedal and I'm doing 220 km/h without even feeling it and look, I'm in Salzburg already! When I'm on Linux, I'm in that idiotic Prius abomination again: not only do I not have any power, but I end up using more fuel too, even though it's a hybrid, and I'm on I-80 somewhere in Iowa. That's how I'd compare SmartOS to Linux.

Post reply on HN