5 ms·

Thanks for sharing a fun read. Bitkeeper was neat, and my overall take on it mirrors Larry McVoy's: I wish he had open sourced it, made his nut running somethi

Thanks for sharing a fun read. Bitkeeper was neat, and my overall take on it mirrors Larry McVoy's: I wish he had open sourced it, made his nut running something just like github but for Bitkeeper, and that it had survived. I only had one interaction with him. In the early '00s, I had contributed a minor amount of code to TortoiseCVS. (Stuff like improving the installer and adding a way to call a tool that could provide a reasonable display for diffs of `.doc` and `.rtf` files.) I had a new, very niche, piece of hardware that I was excited about and wanted to add support for in the Linux kernel. Having read the terms of his license agreement for Bitkeeper, and intending to maintain my patches for TortoiseCVS, I sent him an email asking if it was OK for me to use Bitkeeper anyway. He told me that it did not look like I was in the business of version control software (I wasn't!) and said to go ahead, but let him know if that changed. I use git all the time now, because thankfully, it's good enough that I shouldn't spend any of my "innovation tokens" in this domain. But I'd still rather have bitkeeper or mercurial or fossil. I just can't justify the hit that being different would impose on collaboration.

nmz 2y ago
I wouldn't put fossil in that list of collaboration, since its not really a collaborative tool, or more like, there are barriers to that collaboration, like creating a username for each fossil repository. That's a huge barrier in my view. It would be nice if there was something like a general auth identity that can be used everywhere but that's still not implemented. FWIW, mercurial seems to have an advantage over git, and that support for BIG repositories which seems to be provided by facebook of all people, so until facebook moves to git, mercurial lives on.
- thunderbong 2y ago
  You can have one repository and link all the others to it via "Login Groups" https://www.fossil-scm.org/home/doc/trunk/www/caps/login-groups.md https://www.fossil-scm.org/home/doc/trunk/www/caps/login-gro...
- phyrex 2y ago
  Facebook doesn’t really use vanilla mercurial but its own scale-oriented rust fork. It’s open sourced as “sapling”
sunshowers 2y ago
Like I tell lots of people, check out Jujutsu. It's a very Mercurial-inspired-but-better-than-it UI (the lead dev and I worked on Mercurial together for many years) with Git as one of the main supported backends. I've been using it full time for almost a year now.
- JoshTriplett 2y ago
  I would love to use jujutsu, and it seems like a great model. I think it'd be a bad outcome if the world starts building top a piece of software with a single company owner and a CLA, though. I hope that the CLA goes away one day.
  - sunshowers 2y ago
    Note that the CLA does not transfer copyright, so "single company owner" is not accurate from a copyright perspective.
    - JoshTriplett 2y ago
      It's accurate from the perspective of "there's a single company with the right to change the licensing arbitrarily".
      - ilyagr 2y ago
        No, it is not accurate. That is not what Google's CLA says. (Though there are other CLAs out there that are closer to what you describe) (*Update:* Though IANAL, you should read the child comment and the CLA itself and make up your own mind. https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual. The rest of my comment is mostly independent of the previous paragraph). OTOH, IANAL, but AFAIK anyone can fork `jj` and sell a proprietary product based on jj (and distribute it under pretty much whatever license they like, with very few restrictions) because it is currently Apache licensed, but that is unrelated to the Google CLA. Let me conjecture even more wildly about things I don't know. The following is a guess on my part. One way to interpret this is that Google tends to publish their projects under Apache, and there is no need to demand that people transfer copyright to Google. By releasing your work under Apache, you are already giving Google (or anyone else) all the rights it needs. AFAIK, the main purpose of the Google Individual CLA is to have you sign a statement claiming that you own the rights to your own work and didn't give up those rights to your employer.
yencabulator 2y ago
I was a heavy user of BitKeeper. To me, Git is almost exactly like a ground-up cleaner rewrite of BitKeeper. Gitk and git-gui are essentially clones of the BitKeeper GUI. I don't understand why you'd want to keep using BitKeeper.
- hoistbypetard 2y ago
  I think my memory is probably colored by BitKeeper being my first DVCS. I was never a heavy user of it. I was exposed to BitKeeper when I was managing my team's CVS server. On my next team, we moved to svn, which always felt like cvs with better porcelain from a developer perspective, but when administering that server fell onto my plate, I liked it a lot better than CVS. And I thought BitKeeper would be nicer from a developer perspective. Then on my next team, we used mercurial. I really, really, really liked mercurial, both as a developer and as a dev infrastructure administrator. It also sucked a lot less on Windows than git or BitKeeper. The last time I had to decide for a new team, mercurial and git were the obvious options. I went with git because that was clearly what the world liked best, and because bringing new team members up to speed would require less from me that way. All that goes to say... my direct comparison of git and bitkeeper came from when bitkeeper was mature and git decidedly was not. Then I lumped it in with mercurial (which I really would still prefer, right now) and fossil (ditto). You're probably exactly right about BK.
- cmrdporcupine 2y ago
  Conceptually git is more powerful. But I recall the bitkeeper CLI being far more sensible in its interface.
  - yencabulator 2y ago
    It had its own weird quirks, and sometimes revealed that it was a front for a single file with a lot of funnily-formatted lines. We're just separated from it in time, and you can only truly hate what is familiar.
deleted 2y ago
[deleted]
jdougan 2y ago
It is open source, Apache license 2. Check at https://www.bitkeeper.org/ https://www.bitkeeper.org/
- yjftsjthsd-h 2y ago
  And in light of the history, https://github.com/bitkeeper-scm/bitkeeper https://github.com/bitkeeper-scm/bitkeeper is funny on several levels.
pests 2y ago
He is quoted at the end of the article saying that was what they should have done, and they did have a public offering, but hindsight and yadda yadda.

nmz 2y ago

I wouldn't put fossil in that list of collaboration, since its not really a collaborative tool, or more like, there are barriers to that collaboration, like creating a username for each fossil repository. That's a huge barrier in my view. It would be nice if there was something like a general auth identity that can be used everywhere but that's still not implemented. FWIW, mercurial seems to have an advantage over git, and that support for BIG repositories which seems to be provided by facebook of all people, so until facebook moves to git, mercurial lives on.

thunderbong 2y ago
You can have one repository and link all the others to it via "Login Groups" https://www.fossil-scm.org/home/doc/trunk/www/caps/login-groups.md https://www.fossil-scm.org/home/doc/trunk/www/caps/login-gro...
phyrex 2y ago
Facebook doesn’t really use vanilla mercurial but its own scale-oriented rust fork. It’s open sourced as “sapling”

sunshowers 2y ago

Like I tell lots of people, check out Jujutsu. It's a very Mercurial-inspired-but-better-than-it UI (the lead dev and I worked on Mercurial together for many years) with Git as one of the main supported backends. I've been using it full time for almost a year now.

JoshTriplett 2y ago
I would love to use jujutsu, and it seems like a great model. I think it'd be a bad outcome if the world starts building top a piece of software with a single company owner and a CLA, though. I hope that the CLA goes away one day.
- sunshowers 2y ago
  Note that the CLA does not transfer copyright, so "single company owner" is not accurate from a copyright perspective.
  - JoshTriplett 2y ago
    It's accurate from the perspective of "there's a single company with the right to change the licensing arbitrarily".
    - ilyagr 2y ago
      No, it is not accurate. That is not what Google's CLA says. (Though there are other CLAs out there that are closer to what you describe) (*Update:* Though IANAL, you should read the child comment and the CLA itself and make up your own mind. https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual. The rest of my comment is mostly independent of the previous paragraph). OTOH, IANAL, but AFAIK anyone can fork `jj` and sell a proprietary product based on jj (and distribute it under pretty much whatever license they like, with very few restrictions) because it is currently Apache licensed, but that is unrelated to the Google CLA. Let me conjecture even more wildly about things I don't know. The following is a guess on my part. One way to interpret this is that Google tends to publish their projects under Apache, and there is no need to demand that people transfer copyright to Google. By releasing your work under Apache, you are already giving Google (or anyone else) all the rights it needs. AFAIK, the main purpose of the Google Individual CLA is to have you sign a statement claiming that you own the rights to your own work and didn't give up those rights to your employer.

yencabulator 2y ago

I was a heavy user of BitKeeper. To me, Git is almost exactly like a ground-up cleaner rewrite of BitKeeper. Gitk and git-gui are essentially clones of the BitKeeper GUI. I don't understand why you'd want to keep using BitKeeper.

hoistbypetard 2y ago
I think my memory is probably colored by BitKeeper being my first DVCS. I was never a heavy user of it. I was exposed to BitKeeper when I was managing my team's CVS server. On my next team, we moved to svn, which always felt like cvs with better porcelain from a developer perspective, but when administering that server fell onto my plate, I liked it a lot better than CVS. And I thought BitKeeper would be nicer from a developer perspective. Then on my next team, we used mercurial. I really, really, really liked mercurial, both as a developer and as a dev infrastructure administrator. It also sucked a lot less on Windows than git or BitKeeper. The last time I had to decide for a new team, mercurial and git were the obvious options. I went with git because that was clearly what the world liked best, and because bringing new team members up to speed would require less from me that way. All that goes to say... my direct comparison of git and bitkeeper came from when bitkeeper was mature and git decidedly was not. Then I lumped it in with mercurial (which I really would still prefer, right now) and fossil (ditto). You're probably exactly right about BK.
cmrdporcupine 2y ago
Conceptually git is more powerful. But I recall the bitkeeper CLI being far more sensible in its interface.
- yencabulator 2y ago
  It had its own weird quirks, and sometimes revealed that it was a front for a single file with a lot of funnily-formatted lines. We're just separated from it in time, and you can only truly hate what is familiar.

deleted 2y ago

[deleted]

jdougan 2y ago

It is open source, Apache license 2. Check at https://www.bitkeeper.org/ https://www.bitkeeper.org/

yjftsjthsd-h 2y ago
And in light of the history, https://github.com/bitkeeper-scm/bitkeeper https://github.com/bitkeeper-scm/bitkeeper is funny on several levels.

pests 2y ago

He is quoted at the end of the article saying that was what they should have done, and they did have a public offering, but hindsight and yadda yadda.