
Show HN: BitKeeper – Enterprise-ready version control, now open-source - wscott
https://www.bitkeeper.org/
======
bcantrill
The grand irony is that Larry was one of the earliest advocates of open
sourcing the operating system at Sun[1] -- and believed that by the time Sun
finally collectively figured it out and made it happen (in 2005), it was a
decade or more too late.[2] So on the one hand, you can view the story of
BitKeeper with respect to open source as almost Greek in its tragic scope:
every reason that Larry outlined for "sourceware"[3] for Sun applied just as
much to BK as it did to SunOS -- with even the same technologist (Torvalds)
leading the open source alternative! And you can say to BK and Larry now that
it's "too late", just as Larry told Sun in 2005, but I also think this
represents a forced dichotomy of "winners" and "losers." To the contrary, I
would like to believe that the ongoing innovation in the illumos communities
(SmartOS, OmniOS, etc.) proves that it's never too late to open source
software -- that open source communities (like cities) can be small yet
vibrant, serving a critical role to their constituencies. In an alternate
universe, might we be running BK on SunOS instead of git on Linux? Sure -- but
being able to run an open source BK on an open source illumos is also pretty
great; the future of two innovative systems has been assured, even if it took
a little longer than everyone might like.

So congratulations to Larry and crew -- and damn, were you ever right in 1993!
;)

[1] Seriously, read this:
[http://www.landley.net/history/mirror/unix/srcos.html](http://www.landley.net/history/mirror/unix/srcos.html)

[2] The citation here is, in that greatest of all academic euphemisms,
"Personal communication."

[3] "Sourceware" because [1] predates the term "open source"

~~~
luckydude
Yeah this irony is not lost on me. But in both cases, the companies acted in
self interest. Neither had the guts to walk away from their existing revenue
stream. It's hard to say what would have happened.

It's been an interesting ride and if nothing else, BK was the inspiration for
Git and Hg, that's a contribution to the field. And maybe, just maybe, people
will look at the SCCS weave and realize that Tichy pulled the wool over our
eyes. SCCS is profoundly better.

~~~
adharmad
Thank you for contributing to the development and evangalizing of DVCS,
directly (BK) and indirectly (the ideas and inspiration for git, hg).

~~~
peonicles
It's probably fair to say the DVCS accelerated the growth of the entire
software industry.

Was BitKeeper the first version control system to "think distributed" ?

~~~
lobster_johnson
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](https://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare)

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

~~~
bcantrill
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 to formalize that important history...

[1]
[https://www.usenix.org/legacy/events/lisa11/tech/slides/cant...](https://www.usenix.org/legacy/events/lisa11/tech/slides/cantrill.pdf)

[2]
[https://www.youtube.com/watch?v=-zRN7XLCRhc](https://www.youtube.com/watch?v=-zRN7XLCRhc)

~~~
luckydude
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](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](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.

~~~
muizelaar
There used to be a paper on smoosh here:
[http://www.bitmover.com/lm/papers/smoosh.ps](http://www.bitmover.com/lm/papers/smoosh.ps)
but it's gone now. Do you mind putting it back? I'd like to read it again.

~~~
luckydude
[http://www.mcvoy.com/lm/bitmover/lm/papers/](http://www.mcvoy.com/lm/bitmover/lm/papers/)

------
dsr_
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/](https://lwn.net/Articles/132938/)

~~~
gadders
As I remember it, it was a bit of a douche move by Tridgell, driven by a
Stallman-like free software ideology.

~~~
Mizza
I don't think it's fair to call people douches because they are committed to
their moral principals. Especially so here, where the benefit to humanity over
the alternative is so clearly obvious.

~~~
serge2k
It is when they attempt to force their moral code on others.

Is the benefit clearly obvious? If you actually adhere 100% to Stallman's code
I'm not so sure.

~~~
timv
Tridge made no attempt to force his code on others.

In fact, it was the reverse - he felt like he was being locked out of kernel
development because he didn't want to align his moral code with those who used
BK.

So, he tried to find a way to hold true to his code without forcing the rest
of the kernel team to give up BK.

------
luckydude
Lots of cross platform goodies in there as well as some interesting data
structures. For example, our list data structure is in lines.c, it's extremely
small for a small list and scales nicely to 50K items:

[http://bkbits.net/u/bk/bugfix/src/libc/utils/lines.c?PAGE=an...](http://bkbits.net/u/bk/bugfix/src/libc/utils/lines.c?PAGE=anno&REV=56cf7e34BTkDFx47E54DPNG51B2uCA)

------
to3m
1 year ago:
[https://news.ycombinator.com/item?id=9330482](https://news.ycombinator.com/item?id=9330482)

What changed? Is BitKeeper still an ongoing business with some other model, or
is that, as they say... it? I hope not.

~~~
luckydude
This is to answer this question and all the "too late" comments.

Too late? Maybe. But we had a viable business that was pulling in
millions/year. The path to giving away our stuff seemed like:

    
    
         step 1: give it away
         step 2: ???
         step 3: profit!
    

And still does. So what changed? Git/Github has all the market share. Trying
to compete with that just proved to be too hard. So rather than wait until we
were about to turn out the lights, we decided to open source it while we still
had money in the bank and see what happens. We've got about 2 years of money
and we're trying to build up some additional stuff that we can charge for.
We're also open to being doing work for pay to add whatever it is that some
company wants to BK, that's more or less what we've been doing for the last 18
years.

Will it work? No idea. We have a couple of years to find out. If nothing pans
out, open sourcing it seemed like a better answer than selling it off.

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

~~~
jason_s
^^ 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.

~~~
marcinkuzminski
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

~~~
luckydude
We would love that. Contact dev@bitkeeper.org if you have any
questions/issues.

------
civilian
I have some questions about Why.html:
[https://www.bitkeeper.org/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 large projects is simply much faster than
> competing solutions for most common commercial configurations and
> operations… especially ones that include remote teams, large binary assets,
> and NFS file systems._

Is there a rule of thumb for what size of repos benefits from BK? (And I
suppose size could either be the size of a current commit or the total size of
the repo.)

Are there any companies like github or bitbucket that support BitKeeper repos?

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

~~~
thspimpolds
I think you guys undersell BAM. That was such a clutch feature where i used
BK. It's sad seeing git large file handling just show up, I garuntee it has a
long way to go to get parity with BAM.

------
stephenr
Amongst all the "too late I loves me some git" type comments, i figure I'd say
thankyou and good luck with continued revenue.

I haven't read much about bk so far, so forgive my lazy web question: does/can
bk operate over standard ssh as git/hg/svn can, or does it _require_ a
dedicated listening server to connect to?

Edit: answering my own question, yes it does support ssh as a transport

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

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

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

~~~
manquer
late does not mean it is useless.

The argument diversity is good is not so simple true, there are tones of
benefits to diversity however there is cost to it too: fragmented finding
talent, support, time to fix bugs, more eyes on the project, developer
headaches in supporting competing standards so on...

------
teddyh
BitMover still holds all the copyright, and have all the developers. They
obviously _wanted_ to keep BitKeeper proprietary, and are only doing it now
when facing irrelevance in the marketplace. If BitKeeper becomes popular
again, who’s to say they won't take development proprietary again? Sure, the
community could fork the latest free version, but there _isn’t_ a free
development community for BitKeeper – they’re all internal to BitMover.

------
adrianN
Why would I want to use this over git or mercurial?

~~~
desdiv
You wouldn't, unless you have very specific niche needs. They're pretty
upfront about it:

>Why use BitKeeper when there are lots of great alternatives?

>For many projects, the answer is: you shouldn’t.

[https://www.bitkeeper.org/why.html](https://www.bitkeeper.org/why.html)

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

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

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

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

------
paradite

      $ bk clone bk://bkbits.net/bkdemo/bk_demo
      $ cd bkdemo
      # edit files using your favorite editor
      $ bk -Ux new
      $ bk commit -y"Comments"
      $ bk push
    

As a user whose first CVS was git, I am quite confused by this "quick demo", I
have no idea what "-uX" means, no idea what "new" means, no idea what "-y"
means and why it is immediately followed by quotation marks instead of being
separated by a single space. If bk wants to get new users onboard, it needs a
better quick demo that makes sense to new users.

~~~
masklinn
According to
[http://www.bitkeeper.com/testdrive](http://www.bitkeeper.com/testdrive):

* The -U option to bk tells it to operate on "user files". That is files that are not part of the BitKeeper metadata

* The modifier x corresponds to "extras", files which Bitkeeper doesn't know about (changed files is c)

* `new` adds files to the repository

* [on commit] the -y option is for changeset comments (~commit messages)

So `bk -Ux new` is `git add <untracked files>`[0] and `bk commit -y"thing"` is
`git commit -m "thing"`

[0] aka `git add $(git ls-files -o --exclude-standard)` or `git add -i<RET>
<a> <*> <q>`

------
qwertyuiop924
Too late to dominate, but maybe not too late to cut itself a niche. It seems
to have some advantages over the competition, and appears to be a reasonable
contribution to the table. Besides, competition is always good.

At the very least, Bryan Cantrill will be happy :-D.

~~~
clacke2
As you can see. :-)

[https://news.ycombinator.com/item?id=11668678](https://news.ycombinator.com/item?id=11668678)

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

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

~~~
Jare
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?

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

~~~
Jare
Thank you!

------
rburhum
This is very cool... but also, kind of a bit late. The market already adopted
git and the momentum is there. Unless there is a trivial way to switch back
and forth from git or there is something that is orders of magnitude better,
this is a decade too late.

~~~
tommoor
'A bit late' might be understatement of the day :)

------
devnonymous
Great news! Better late than never! I hope they (or a client of theirs) create
a BK backed service soon. I for one, think we need more than just github and
altassian in the market if only to ensure the businesses don't take their
users for granted (hint: sourceforge)

~~~
ashitlerferad
There are tons of alternatives to github/atlassian/sourceforge:

[https://en.wikipedia.org/wiki/Comparison_of_open_source_soft...](https://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities)

------
jeremycole
Huh. Thanks for doing this. As a MySQL employee in the early days I used
BitKeeper and fell in love with it and kept using it as long as I could. I
mainly use Git these days, but frequently miss BitKeeper -- BK felt a lot more
natural to me than Git ever has.

~~~
luckydude
Hey Jeremy, long time no talk. We have the MySQL 6.x tree in BK, we can put up
on bkbits if you like.

------
PuercoPop
Something I'm wondering and the man page doesn't clear, does it track files
across renames or does it only track content like git?

~~~
luckydude
It tracks renames, it's not like git. Every file has an internal identifier,
that's the actual file id, the name is a versioned attribute of the file.

~~~
glandium
What's not clear from your replies is whether it tracks renames like
mercurial, by having users run a manual command to ensure the VCS know about
the rename. Except if bk has a file system monitor, I'll assume that's what it
does. Unfortunately, data on a few Mercurial repositories I looked at
(Mozilla's and Mercurial's) shows that people don't mark all file renames.

~~~
neandrake
The only way I'm familiar with instructing mercurial to do this is with

    
    
        hg addremove -s
    

Is there another way to indicate a rename?

------
drewg123
Can it import from git or SVN or mercurial?

Looking at the bk import man page, it looks like it cannot import from any
modern VCS. I see only RCS, SCCS, CVS, and MKS as options. This is
unfortunate, as I have a mercurial tree I'd like to import.

~~~
ob
We have a git importer but it's not part of the "official" repo as there are
still a few corner cases. I am afraid we don't have a mercurial importer
though...

~~~
drewg123
You probably should publish the git importer -- it makes it really hard to try
bitkeeper if you have to play with a pretend tree.

~~~
ob
Yeah, we're trying to figure out how to do that.

~~~
voltagex_
+1 would definitely give it a try with this feature

~~~
thspimpolds
Same here, I want to get back to my BK love

------
jordigh
Well, that took a long time... I wonder what changed in the eleven years that
Git and Mercurial were deployed to replace bitkeeper.

------
kingosticks

        "The ability to seamlessly share only a subset of your source tree "
    

I've spent a good 10 mins trying to find anything specific in the
documentation about this but come up empty. Is this just by virtue of using
submodules, ssh and filesystem permissions or is there something more that I'm
yet to find? The lack of fine grain security on modern VCS systems is one of
the reasons our monolithic repository is still using CVS.

On a related note, the getting started documentation should be more prominent
on the Web page.

------
Annatar
The biggest feature for me is the efficient handling of large binary files,
because it means I could finally have a completely self-contained repository
(clone and everything is in one place, plus free replication), but without the
performance penalties which for example Mercurial incurs with binary files:

[https://www.bitkeeper.org/why.html](https://www.bitkeeper.org/why.html)

I have to try it out just for that!

------
okket
There is an official mirror on GitHub:

[https://github.com/bitkeeper-scm/bitkeeper](https://github.com/bitkeeper-
scm/bitkeeper)

~~~
luckydude
It's a read only mirror, the read/write mirror is on bkbits.net. But we'll
maintain the mirror (or you can, bk has fast-export which creates a perfect
mirror in git).

~~~
sdesol
Would you describe the exporting process to git, pretty painless? If so, I'll
look at adding bitkeeper support for my git analytics/search tool. I've
uploaded some pictures that shows what the git repos that you have hosted on
GitHub looks like at:

[http://imgur.com/a/nVvov](http://imgur.com/a/nVvov)

Since the export process adds "bk: <changeset>" to the commit comment, it'll
be easy to tell that it was created via your fast-export tool, which means my
tool can easily point you back to the bitkeeper web interface.

------
ausjke
This predates git, in fact if it was open sourced from the start git may never
have existed, sigh, how ironic.

If bitkeeper was open sourced it could be a powerhouse nowadays, open source
and commercially. Now it is too late and honestly irrelevant.

------
prirun
I think the same points made in Larry's 1993 paper could be made about various
Linux distributions:

    
    
      Why a gazillion package managers?
      Why not a common filesystem layout?
      Why not a standard desktop?
    

IMO, Linus should enforce his Linux trademark by forcing every distribution to
follow a set of standards. If they don't, they can't call it "Linux". If he
got them in a room and said "This is the way it's going to be, or else",
they'd do it.

~~~
JdeBP
The people that you are looking for are the systemd and FreeDesktop people.
The former have a manifesto addressing this:

> _The emphasis of systemd to provide a platform instead of just a component
> allows for closer integration, and cleaner APIs. Sooner or later this will
> trickle up to the applications. Already, there are accepted XDG
> specifications [...] that are not supported on the other init systems._

> _systemd is also a big opportunity for Linux standardization. Since it
> standardizes many interfaces of the system that previously have been
> differing on every distribution, on every implementation, adopting it helps
> to work against the balkanization of the Linux interfaces._

\--
[http://0pointer.net/blog/projects/why.html](http://0pointer.net/blog/projects/why.html)

They have a systemd filesystem layout that they say modernizes the FHS:

* [https://freedesktop.org/software/systemd/man/file-hierarchy....](https://freedesktop.org/software/systemd/man/file-hierarchy.html)

They have a project to rearchitect packaging:

* [http://0pointer.net/blog/revisiting-how-we-put-together-linu...](http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html)

They have the aforementioned specifications:

* [https://specifications.freedesktop.org/](https://specifications.freedesktop.org/)

* [https://www.freedesktop.org/wiki/Specifications/](https://www.freedesktop.org/wiki/Specifications/)

They have a systemd DNS client:

* [https://www.freedesktop.org/wiki/Software/systemd/writing-re...](https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients/)

They even have events where people get in a room to be told "the way it's
going to be":

* [https://news.ycombinator.com/item?id=10519578](https://news.ycombinator.com/item?id=10519578)

* [https://ti.to/systemdconf/systemdconf-2016](https://ti.to/systemdconf/systemdconf-2016)

------
foreign-inc
Some history from Linus himself
[https://www.youtube.com/watch?v=4XpnKHJAok8](https://www.youtube.com/watch?v=4XpnKHJAok8)

------
loeg
Interesting — FreeBSD 7 and 8 binaries available for download. Neither of
those is a current supported release. It's like offering RHEL 3 or 4 binaries.

~~~
wscott
We found that by maintaining a build cluster with many old releases we tend to
keep compatibility issues out of the code. Also, FreeBSD is very good about
backwards compatibility so current releases will run these binaries just fine.

However we will update the build targets as needed by users.

~~~
X86BSD
+1 For FreeBSD support +1 For open sourcing BK

I hope it works in your best interest. And I wish you all at BK the absolute
best and thank you for all your incredibly hard work over the years.

------
rdtsc
I see this as "features"
[https://www.bitkeeper.org/why.html](https://www.bitkeeper.org/why.html)

See large repo support, security and others.

Is that geared towards comparing with Git/Github? Is there a more focused
comparison with those. i.e. both comparing to git itself and to GaaS (Git as a
Service).

------
paulasmuth
The nested repository feature sounds amazing. Dealing with both git submodules
and git subtrees has been a huge pain for me.

I'm looking forward to trying this out over the weekend. Is there some kind of
util/script to import history from git?

~~~
luckydude
Working on getting a crappy one out there, we have simple and pretty crappy
and complex / fragile but less crappy.

------
jwilk
"[...] Linus moved to it and most of the developers followed. They stayed in
it for three more years before moving to Git because BitKeeper wasn't open
source."

Um, the "because" part is not quite right.

~~~
clacke2
Glosses over things, but is essentially accurate. Lots of people were not
willing to use a proprietary tool, which prompted some reverse-engineering,
which caused BK to withdraw their offer.

If all free software activists had accepted the compromise of using the free-
as-in-beer BK, git would never have been created.

------
benjarrell
Does this come with any sort of web interface?

~~~
luckydude
Yes, there is hosting at bkbits.net and if you drill down to

[http://bkbits.net/u/bk/bugfix/](http://bkbits.net/u/bk/bugfix/)

that's bk/web which is included in the release.

------
gbraad
Great to see this finally happen... However, for 'us' Git remains a keeper.

------
talles
Too late?

------
ashitlerferad
Too late :)

~~~
luckydude
You and a lot of other people say that. Sure, if we want to take over from
Git, it's late. But Git has left us with an opening, the only way Git works
for the masses is Github, Git itself is too complicated and people "lose"
their data (they don't but Git makes it appear like they did).

I think people will play with BK and find out that it can work for everyone
without something like Github (we still need it but it's a nice to have, not a
requirement).

We'll see. When I was proposing BK the intertubes said it would never work.
I'm a little skeptical of the nay sayers.

~~~
burfog
Nah, it's easy. Before every git command, I just tar up the source. When git
complains, I can untar to get things working again. To work with others, I
fetch a new tree and then use "diff" and "patch" to merge my changes into the
new tree.

(seriously, as an experienced professional developer, I actually do this much
of the time)

~~~
setpatchaddress
Seriously? Your life would be easier if you simply learned to use git
properly.

~~~
burfog
Well, it's that bad. When I try to do things the "right" way I'm constantly
exposed to the innards of git. I don't care about that stuff. It's
complicated. It's a distraction from, you know, the actual task I was trying
to do before git got involved.

I've done significant work with 5 other version control systems, including
BitKeeper and ClearCase. Nothing is as difficult as git. At this point, I give
up. Screw it.

I can do diff, tar, and patch. I have an editor. That'll do. I won't miss the
confusing errors. Most importantly, I trust that these simple tools will not
eat my work.

------
ezoe
It's too late. There is no reason to use non-git DVCS in 2016.

