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

241–250 of 309 posts

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

#241

Post by ryao »

ryao wrote: post #145
bcantrill wrote: post #37

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 "sourcewar…

Bit keeper is a great example of what happens when you do not open source your code. I have cited it that way many times.

I have no idea why people are down voting this. In an alternative universe, we would all be using bit keeper. The reason we are not is mainly because Larry McVoy ceded the market to git and mercurial because he was afraid of disrupting his existing business. git and mercurial would never have existed had he practiced at Bit Movers what he preached at Sun.

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

#242

Post by qb45 »

namdnay wrote: post #232
qb45 wrote: post #205

Earlier quoted context omitted.

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

OK, that makes sense. I imagined that hg implicitly updates remote working set and that parent complained about git's behavior because

  hg push ssh://testing-server/
worked as lazy man's single command deployment for him :)

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

#243

Post by wtetzner »

vvanders wrote: post #67
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.

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.

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

#244

Post by wyoung2 »

Frondo wrote: post #175
luckydude wrote: post #32

Earlier quoted context omitted.

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…

Here's my dream DVCS: easily self-hostable like Fossil, but with good wiki and ticketing system. (Fossil's wiki and ticketing system are awful, but what really sunk it for me was its unexpected behavior for basic commands like "fossil rm".) I'm just not super-fond of relying on Bitbucket, reliable though they've been, for hosting my stuff. But a package I could toss on my own VPS? I'd toss some money at that. Wouldn'…

> Fossil's wiki and ticketing system are awful

Care to be more specific?

I'll grant that Fossil's wiki is not a competitor to MediaWiki, but that doesn't make it "awful." It just makes it less featureful. So, what feature do you need in a wiki that Fossil's wiki does not provide?

As for the ticketing system, again, it isn't going to replace the big boys out of the box, but it also doesn't have to match them feature-for-feature to be useful. Also, the Fossil ticketing system's behavior is not fixed: it can be modified to some extent to behave more like you need. Did you even try modifying its behavior, or are you just complaining about its out-of-the-box defaults? Be specific!

> unexpected behavior for basic commands like "fossil rm".

If you mean that you want fossil rm to also delete the checkout copy of the file in addition to removing it from the tip of the current branch, and you want fossil mv to rename the checkout copy in addition to renaming it in the repository, then you can get that by building Fossil with the --with-legacy-mv-rm flag, then setting the mv-rm-files repository option. You can enable it for all local Fossil repositories with "fossil set mv-rm-files 1".

Alternately, you can give the --hard flag to fossil mv and fossil rm. That works even with a stock binary build of Fossil.

> I'm just not super-fond of relying on Bitbucket

For some of us, relying on a cloud service just isn't an option. We're willing to give up many features in order to keep control of our private repositories.

> a package I could toss on my own VPS? I'd toss some money at that.

Fossil runs great on a VPS, even a very small one, due to its small footprint. I wrote a HOWTO for setting it up behind an nginx TLS proxy using Let's Encrypt here:

https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...

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

#245

Post by mankash666 »

luckydude wrote: post #58
appleflaxen wrote: post #54

Earlier quoted context omitted.

Thanks for providing this level of detail; it's interesting to see the considerations that went into your decision. How / why did you decide to use the Apache license rather than the GPL? (It seems like a viral license might protect you a little bit, if you want to prevent your competitors from forking and improving your code base and then using it to compete against you.)

We decided to go all in on open source. Given our history, anything but a "here ya go" license wasn't going to go over well. We're aware that someone could fork it and compete against us, good on them if they can. Making money in this space isn't easy and if they can do better than us we'll ask 'em for a job. We know the source base :) As to why that license, I think it was because LLVM or clang or both had recently…

Please do not GPL this! You've made the sensible choice. Your analysis on making money is spot on.

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

#246

Post by ob »

rbsmith wrote: post #222
caf wrote: post #154

Earlier quoted context omitted.

It's sort of suprising then that a delete doesn't just and end-version on the insert instead: ^AI 1..2 this is the first line in the first version. ^AE 1..2 ^AI 2 this is the line that was added in the second version ^AE 2 This way the reconstruction process wouldn't need to track blocks-within-blocks.

Interesting. "^AI Spec" where Spec feeds into a predicate f(Spec, Version) to control printing a particular Version? Looks like you could drop the ^AE lines.

Sounds like equivalent representations no? Limit the scope of the I lines or wrap them in D lines.

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

#247

Post by qwertyuiop924 »

peatmoss wrote: post #234
SwellJoe wrote: post #115

Earlier quoted context omitted.

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

Ah, the agony that I can only imagine. The many Linux distros are bad enough...

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

#248

Post by qwertyuiop924 »

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?

Shell scripts are even more miserable to write than perl, and are missing a lot of features you want for most applications

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

#249

Post by qwertyuiop924 »

jschwartzi wrote: post #235
ryao wrote: post #230

Earlier quoted context omitted.

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

Or LISP.

Firstly, the mention of LISP would have probably sent most of Sun screaming and running for the hills at the time. Secondly, LISP has never been very good at OS integration, one of the most important things for many software projects.

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

#250

Post by nickpsecurity »

Annatar wrote: post #206
nickpsecurity wrote: post #75

Earlier quoted context omitted.

I really doubt it. There's not enough demand to make them competitive in price-performance. The server chips have stayed badass but still niche market. There's even open-source, SPARC HW with reference boards for sell from Gaisler. That didn't take off. I liked the desktops but there's no money in them. Market always rejects it. So does FOSS despite it being the only open ISA with mainstream, high-performance impleme…

> There's not enough demand to make them competitive in price-performance. There does not need to be demand: Steve Jobs (in)famously said that where there was no market, "create one". I for one would absolutely love to be able to buy an illumos-powered A4-sized tablet which ran a SPARC V9 instruction set, plugged into a docking station, and worked with a wireless keyboard and mouse to be used as a workstation when I'…

"There does not need to be demand: Steve Jobs (in)famously said that where there was no market, "create one"."

What people forget is that Steve Jobs was a repeated failure at doing that, got fired, did soul-searching, succeeded with NEXT, got acquired, and then started doing what you describe. Even he failed more than he succeeded at that stuff. A startup trying to one-off create a market just for a non-competitive chip is going to face the dreaded 90+% failure rate.

"But the most important point was, and still is, and always will be: it has to cost as much as the competition, or less."

That's why the high-security stuff never makes it. It takes at least 30% premium on average per component. I totally believe your words fell on deaf ears at Sun. I'd have bought SunBlades myself if I could afford them. I could afford nice PC's. So, I bought nice PC's. Amazing that echo chamber was so loud in there that they couldn't make that connection.

"I for one would absolutely love to be able to buy an illumos-powered A4-sized tablet which ran a SPARC V9 instruction set"

That's actually feasible given the one I promote is 4-core, 1+GHz embedded chip that should be low power on decent process node.

http://www.gaisler.com/index.php/products/processors/leon4?t...

The main issue is the ecosystem and components like browsers with JIT's that must be ported to SPARC. One company managed to port Android to MIPS but that was a lot of work. Such things could probably be done for SPARC as well. The trick is implementing the ASIC, implementing the product, porting critical software, and then charging enough to recover that but not more than competition whose work is already done for them. Tricky, tricky.

Raptor's Talos Workstation, if people buy it, will provide one model that this might happen. Could get ASIC's on 45-65nm really quick, use SMP given per-chip cost is $10-30, port Solaris/Linux w/ containers, put in a shitload of RAM, and sell it for $3,000-6,000 for VM-based use and development. It would still take thousands of units to recover cost. Might need government sales.

Post reply on HN