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

231–240 of 309 posts

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

#231

Post by luckydude »

nullnix wrote: post #216
qwertyuiop924 wrote: post #213

Earlier quoted context omitted.

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

We support the uuencode horror for compat (and for smaller binaries that don't change) but the answer for binaries is BAM, there is no data in the weave for BAM files.

I don't agree that the weave is horrible, it's fantastic for text. Try git blame on a file in a repo with a lot of history then try the same thing in BK. Orders and orders of magnitude faster.

And go understand smerge.c and the weave lightbulb will come on.

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

#232

Post by namdnay »

qb45 wrote: post #205
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…

> Now that almost works, except the `git branch; git checkout` flow is not the proper way to push changes in the working directory to the new branch. (The context of the conversation was stuff that was already being developed, presumably on the master branch.) > But, I mean, close enough. It's `git stash branch ` and it generates an ugly error message but it does exactly what you want it to do, so you can ignore that…

Regarding 2 - Do you mean the destination repo has uncommitted changes? There is no need to nuke them, as pushing to this repo will have no influence on the working set: it will just add new changesets in the history!

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

#233

Post by stonemetal »

Mathiasdm wrote: post #176
stonemetal wrote: post #34

Earlier quoted context omitted.

It claims to be able to handle binary files well which would be a big deal to game development. They have mostly passed on git and mercurial since they can't handle game assets.

Mercurial has had 'largefiles' since Mercurial 2.0, 5 years ago.

While it is better than git at working with large files, the large file extension doesn't solve the problem 100%.

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

#234

Post by peatmoss »

SwellJoe wrote: post #115
qwertyuiop924 wrote: post #107

Earlier quoted context omitted.

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 makef…

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

Truer words have ne'er been spoken. My first big boy job involved building and maintaining a large open source stack on top of AIX. These days I occasionally experience hiccups related to OpenBSD not being Linux. Problems aren't even in the same league. That said, the thrill of getting stuff to work on AIX was certainly greater (and purchased with more human suffering).

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

#235

Post by jschwartzi »

ryao wrote: post #230
qwertyuiop924 wrote: post #212

Earlier quoted context omitted.

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 caugh…

> there really wasn't much else out there in the field. What about shell scripts?

Or LISP.

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

#236

Post by rkangel »

ryao wrote: post #185
dsr_ wrote: post #9

For people who don't know the history -- McVoy offered free bitkeeper licenses to various open source projects, and the Linux kernel switched to it. After Andrew Tridgell (SAMBA, among other projects) reverse-engineered the bitkeeper protocol [1] in order to create his own client, the license was rescinded for everyone. As a result, Linus wrote git. [1] https://lwn.net/Articles/132938/

From what I read, he connected to a bit keeper repository via telnet on port 5000, executed the help command and then used that information to write an incomplete client. That does not sound like reverse engineering to me.

It is reverse engineering. It's just easy reverse engineering.

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

#237

Post by jschwartzi »

Annatar wrote: post #218
lukaslalinsky wrote: post #190

Earlier quoted context omitted.

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

It's probably the same idea as the one behind committing once in Mercurial and then using commit --amend repeatedly as you refine the changes. Git's method sounds like it avoids a pitfall in that method by holding your last changeset in a special area rather than dumping it into a commit so that you can't accidentally push it.

I often amend my latest commit as a way to build a set of changes without losing my latest functional change.

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

#238

Post by Jare »

luckydude wrote: post #131
Jare wrote: post #114

Earlier quoted context omitted.

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?

We open sourced everything . So yes, it's there. The commercial site is out of date. We have not done the centralized lock manager, we didn't get commercial demand for that (yeah, surprised me too). We could do it though, it's not that hard.

Thank you!

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

#239

Post by SEJeff »

dave2000 wrote: post #105
SwellJoe wrote: post #60

Earlier quoted context omitted.

I've read that "sourceware" article before, in the distant past when it was still a roughly accurate picture of the market (maybe 1995 or 1996). It's weird to read it again now, in a world that is so remarkably changed. Linux, the scrappy little upstart with a million or so users at the time of the paper, is now the most popular OS (or at least kernel) on the planet, powering billions of phones and servers. NT was vi…

"I'm a bit concerned that it's going to be Android, however, that wins the mobile world since Android is nowhere near the ideal OS from an Open Source and ethical perspective; but, I guess they got the bits right that Larry was suggesting needed to be right." They've already won; Apple isn't coming back (did they "go thermonuclear" in the end or did that nonsense die with Mr Magical Thinking?). Don't confuse Android…

Not really. AOSP died when Jean-Baptiste Queru quit in protest out of AOSP not really being open source. He works at Yahoo now.

http://www.engadget.com/2013/08/07/aosp-maintenance-head-lea...

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

#240

Post by SEJeff »

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…

No, the git equiv of svn up is not git pull, but git pull --rebase.
Post reply on HN