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

111–120 of 309 posts

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

#111

Post by emn13 »

drostie wrote: post #109
dsp1234 wrote: post #98

Earlier quoted context omitted.

"hey, can you branch the code to commit those changes and push them to the testing server? This thing's really cool and we don't mind playing with the alpha version, but we might scrap it all later." Are they talking about hg or git here. Because that flow in git is: git branch git checkout git commit git push The only thing that git adds to that workflow is that creating a new branch doesn't immediately move you ont…

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.

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

#112

Post by chris_wot »

luckydude wrote: post #83
atombender wrote: post #79

Earlier quoted context omitted.

Sun's TeamWare [1] was probably the first real distributed version control system. It worked on top of SCCS. Larry McBoy, BitKeeper's creator, was involved in its development. I believe BitKeeper also uses parts of SCCS internally. [1] https://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare

We did a clean room reimplementation of SCCS and added a pile of extensions.

So basically when Tridge "reverse engineered" BK, he basically reimplemented SCCS?

https://lwn.net/Articles/132938/

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

#113

Post by kazinator »

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

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

#114

Post by Jare »

luckydude wrote: post #31
sspiff wrote: post #29

I'm wondering: how does it handle large binary files? Any better than git or hg without extensions?

Yes. Binaries are handled by one or more servers, we call them BAM servers. The servers hold the data and your repo holds the meta data, binaries are fetched on demand. You can have a cloud of servers so the binaries are "close" (think China, India, US).

Two questions:

It is unclear to me if the BAM server is part of this opensourcing or not. The page talks about a 90-day trial.

Also, it is common in other (usually non-D)VCS workflows to lock binary files while working on them, since concurrent changes can't be merged the way text files allow. Does BK support anything like this?

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

#115

Post by SwellJoe »

qwertyuiop924 wrote: post #107
SwellJoe wrote: post #99

Earlier quoted context omitted.

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…

Fair 'nuff. And no, I haven't used commercial UNIXes all that much, but I have experienced plenty of Linux's warts. I do agree with a lot of those points, but containers on Linux just aren't there, systemd is a mess that's going to get pushed in no matter what we say, and there are plenty of issues to be had, although the ladder is true of any UNIX. If you want to know what the rest of the issues are, just start goog…

Those issues seem so trivial with the benefit of hindsight and a memory of what it was like to deploy an application to multiple UNIX variants. Having one standard (we can call that standard "it ain't quite POSIX, but it runs great on Linux") is so superior to the mine field that was all of the UNIXen in 199x, that I don't even register it as a problem. Shoot, until you've had to use autotools or custom build a makefile for a half dozen different C compilers, kernels, libc, and so on, you don't know from POSIX "standards" pain.

But now my beard is showing and I'm ranting. My point is this: it took something from completely outside of the commercial UNIX ecosystem, so far out in left field that none of the UNIX bosses (or Microsoft) saw it as a threat until it was far too late...and it took something that was good, really good in at least some regards, that it would have passionate fans even very early in. Linux did that. And, compared to everything else (pretty much everything else that's ever existed, IMHO), it's great.

And, I'm on board the retro computing bandwagon. I have a real live Commodore 64 and an Atari 130xe. I'd like to one day find an Amiga 1200 in good shape, but because I live in an RV and travel fulltime, I don't have a lot of room to spare. But I do like to tinker and reminisce.

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

#116

Post by danielbot »

qwertyuiop924 wrote: post #94
atombender wrote: post #79

Earlier quoted context omitted.

Sun's TeamWare [1] was probably the first real distributed version control system. It worked on top of SCCS. Larry McBoy, BitKeeper's creator, was involved in its development. I believe BitKeeper also uses parts of SCCS internally. [1] https://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare

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

BK and Monotone begat Git

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

#117

Post by drewnoakes »

qwertyuiop924 wrote: post #92
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…

Git's attitude, AFAIK, is that if you want per-file comments, make each file its own checkin. There are pros and cons to this. Performance as a feature, OTOH, is one of Linus's three tenets of VCS. To quote him, "If you aren't distributed, you're not worth using. If you're not fast, you're not worth using. And if you can't guarantee that the bits I get out are the exact same bits I put in, you're not worth using."

I suppose that in Git if you wanted to group a bunch of these commits together you could do so with a merge commit.

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

#118

Post by danielbot »

nickpsecurity wrote: post #77
drostie wrote: post #72

Earlier quoted context omitted.

It's astonishing to me that Git has won out given how much easier it's been for me to explain Hg to other people than to explain Git. To this day, in our SVN workflow at my company, nontechnical people who have merely seen a Hg diagram on a whiteboard by my desk immediately grasped the idea and the lingo, and ask me questions like "hey, can you branch the code to commit those changes and push them to the testing serv…

This applied to me as well. I like the metaphor someone wrote that Git is the assembly language of DCVS.

Maybe so, but it's missing some important instructions having to do with directories and renames

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

#119

Post by justinclift »

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

Wonder if BitKeeper might be a viable alternative for Git LFS (https://git-lfs.github.com) then.

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

#120

Post by ob »

Jare wrote: post #114
luckydude wrote: post #31

Earlier quoted context omitted.

Yes. Binaries are handled by one or more servers, we call them BAM servers. The servers hold the data and your repo holds the meta data, binaries are fetched on demand. You can have a cloud of servers so the binaries are "close" (think China, India, US).

Two questions: It is unclear to me if the BAM server is part of this opensourcing or not. The page talks about a 90-day trial. Also, it is common in other (usually non-D)VCS workflows to lock binary files while working on them, since concurrent changes can't be merged the way text files allow. Does BK support anything like this?

The BAM server is part of the open source version. The 90-day trial is for the enterprise version (which is the same version, only with commercial support).

BitKeeper doesn't support locking binary files.

Post reply on HN