Comment by luckydude | Hacker News Reader

Comment by luckydude | Hacker News Reader

Parent Full thread

Probably the single biggest reason, aside from it's easier to use than git's CLI, is that it has sub-modules that work exactly like files do in a repository. No extra options, just clone/pull/push/commit/etc. Full on distributed workflow.

BitKeeper itself is a collection of repositories. Download an install image, install, and clone it:

    $ bk clone http://bkbits.net/u/bk/bugfix
    $ cd bugfix
    $ bk here
    PRODUCT
    default
    $ bk comps -m
    ./src/gui/tcltk/bwidget
    ./src/gui/tcltk/tcl
    ./src/gui/tcltk/tk
    ./src/gui/tcltk/tkcon
    ./src/gui/tcltk/tktable
    ./src/gui/tcltk/tktreectrl
    ./src/win32/dll/scc
    ./src/win32/dll/shellx
    ./src/win32/dll/shellx/src
    ./src/win32/msys
    ./src/win32/vss2bk

which shows that what we clone by default doesn't include all that other crud (we cache the build result from that and populate it as needed to do builds).

Play with it, it's very different from Git, the subrepo binding is just like file bindings. Everything works together and obeys the same timeline.

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.

They actually can. There is just no good way to version many file formats. Git-pack would have to be extended with support for feels compression of so many formats it is not even funny. And leaving those files outside version control is as easy as always.

The about only difference is that git prefers the whole history and you cannot yet set per submodule shallow clone policy. It wouldn't even be too hard to add that.

I don't agree about leaving files outside version control - this always ends in tears.

Regarding versioning, you can always version any file by storing every revision and compressing them as best you can. I believe this is what Perforce does. Repo size can of course become an issue, and git doesn't do a great job with that, since it stores everything, and stores it locally. Perforce can at least discard old revisions and lets you select history depth on a per-file or file type basis.

The more serious problem with git in my view is that there's no good automated merging tools for many types of files, nor are any likely to arise. And more importantly, most people working on your average game aren't interested in forming in-depth mental models of how their tools work, and certainly don't want to have to pick up the pieces when they go wrong. So for most files, you need an exclusive lock (check in/check out, lock/unlock, etc.) model, or similar. That works quite well. But for obvious reasons, git just doesn't support this model at all, and I believe Mercurial is the same - and no amount of transparent/magic large file storage backends or whatever are going to fix that.

Some game shops have had good luck with Mercurial's largefiles extension, for what it's worth.

It looks like it doesn't have locking, which is the other half of what you need and why most shops go with Perforce.

I'm not sure how locking would work when you're distributed. It really only makes sense for a centralized VCS.

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

Feature set wise this has a number of great advantages over git! It's a shame all of the tools today are so git-centric in some ways

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.

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.

Yeah, it's a possibility. Just hoping for something better. :)

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.

I really hope that takes off -- I'm interested in something that like Git but which actually makes sense without costing lots of neurons to understand how to use it in practice.

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

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

Reply on news.ycombinator.com