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

121–130 of 309 posts

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

#121

Post by justinclift »

luckydude wrote: post #66
stephenmm wrote: post #64

Earlier quoted context omitted.

If this works well than this indeed is a HUGE reason to use BK!

Try it and let us know. You can download the binaries at bitkeeper.org and then clone the repo like so: $ bk clone http://bkbits.net/u/bk/bugfix/ type make and you should have a working BK built from source.

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.

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

#122

Post by danielbot »

luckydude wrote: post #52
hansihe wrote: post #42

Earlier quoted context omitted.

How does it detect renamed files in the filesystem? Thank you for open sourcing by the way, I can definitely see how some features (binary file handling, submodule handling) could be useful for large-scale projects like games.

Each history file contains it's internal name, much like a file system has an inode # that is the internal name for that file. We call the names "keys" and you can dig out the inode key like so (every delta has a key, the first delta is called the rootkey): $ bk log -nd:ROOTKEY: -r+ slib.c lm@bitmover.com|src/slib.c|19970518232928|52808|f3733b2c327712e5 The key is user@host|relative path|UTC|checksum|64 bits of /dev/…

Not tracking namespace accurately is Git's biggest weakness and would most probably be BK's best argument for getting a tryout. With Git, renaming a file and editing it at the same time tends to make a mess of the history and cause much pain. You can say just don't do that, but I say it happens, and it should just work.

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

#123

Post by luckydude »

bcantrill wrote: post #101
qwertyuiop924 wrote: post #94

Earlier quoted context omitted.

NSE begat NSE-lite begat TeamWare begat BK begat git. Or so says Cantrill.

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 quit because they were forced to use the NSE and it made them dramatically less productive. Nerds hate being slowed down.

Once the whole SCM thing crossed my radar screen I was hooked. Someone had a design for how you could have two SCCS files with a common ancestry and they could be put back together. I wrote something called smoosh that basically zippered them together.

Nobody cared. So I looked harder at the NSE and realized it was SCCS under the covers. I built a pile of perl that gave birth to the clone/pull/push model (though I bundled all of that into one command called resync). It wasn't truly distributed in that the "protocol" was NFS, I just didn't do that part, but the model was the git model you are used to now minus changesets.

I made all that work with the NSE, you could bridge in and out and one by one the kernel guys gave up on NSE and moved to nselite. This was during the Solaris 5.0 bringup.

I still have the readme here: http://mcvoy.com/lm/nselite/README and here are some stats from the 2000th resync inside of Sun: http://mcvoy.com/lm/nselite/2000.txt

I was forced to stop developing nselite by the VP of the tools group because by this time Sun knew that nselite won and NSE lost so they ramped up a 8 person team to rewrite my perl in C++ (Evan later wrote a paper basically saying that was an awful idea). They took smoosh.c and never modified it, just stripped my history off (yeah, some bad blood).

Their stuff wasn't ready so I kept working but that made them look bad, one guy with some perl scripts outpacing 8 people with a supposedly better language. So their VP came over and said "Larry, this went all the way up to Scooter, if you do one more release you're fired" and set back SCM development almost a decade, that was ~1991 and I didn't start BitKeeper until 1998. There is no doubt in my mind that if they had left me alone they would have the first DVCS.

Fun times, I went off and did clusters in the hardware part of the company.

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

#125

Post by luckydude »

emn13 wrote: post #111
drostie wrote: post #109

Earlier quoted context omitted.

Ahahahahahaha. You think that works! No. That fails with the following semi-helpful error message: remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match rem…

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.

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

#126

Post by luckydude »

civilian wrote: post #78

I have some questions about Why.html: https://www.bitkeeper.org/why.html > Spending a lot of time dealing with manual and bad auto-merges? BitKeeper merges better than most other tools, and you will quickly develop confidence in the quality of the merges, meaning no more reviewing auto-merged code. Do you have examples of merge-scenarios that are a Conflict for git but resolve for BK? > BitKeeper’s raw speed for larg…

Wayne pointed to some stuff over on the reddit thread.

As for size it's csets * files, as that gets big, Git slows down faster than linear, we're pretty linear.

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

#127

Post by educar »

I half-expected 'very late' comments before I read the comments. I wasn't disappointed.

For those who commented that way, please reconsider this winner takes all approach to your outlook of the world. The world is better because of choice and it's in everybody's best interest to have more distributed version systems.

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

#128

Post by sytse »

justinclift wrote: post #121
luckydude wrote: post #66

Earlier quoted context omitted.

Try it and let us know. You can download the binaries at bitkeeper.org and then clone the repo like so: $ bk clone http://bkbits.net/u/bk/bugfix/ type make and you should have a working BK built from source.

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.

Consider using Git LFS for binary data, our GitLab.com supports it up to 10GB per project, self hosted installations are limited only by the disk volume.

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

#129

Post by caf »

luckydude wrote: post #50
qwertyuiop924 wrote: post #44

Earlier quoted context omitted.

I though SCCS had the same problems as RCS. What did it do differently?

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

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

?

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

#130

Post by luckydude »

kazinator wrote: post #113

How does BitKeeper scale to large projects? (Like, say, gigabytes of binaries.) This is a weak area of Git. --- From the "Why" page: BitKeeper’s Binary Asset Manager (BAM) preserves resources and keeps access fast by providing local storage as needed. BAM is great for any organization that handles: * Videos * Photos * Artwork * Office files * CAD files * Any large binary files

I've been using BK/BAM for my photos, it's got 56GB of data in there and works great. I cheat because I added a way to check things out that uses hardlinks instead copies and I can check out the whole tree in 6 seconds. Doing the copy takes a lot longer: 9+ minutes. Hardlinks rock.

On the commercial site there is a link to some BAM paper, take a look at that and maybe ask in the forum or irc if this gets lost.

Post reply on HN