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

221–230 of 309 posts

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

#221

Post by manquer »

educar wrote: post #127

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.

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

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

#222

Post by rbsmith »

caf wrote: post #154
luckydude wrote: post #134

Earlier quoted context omitted.

Close. By the way there is a bk _scat command (sccs cat, not poop) that dumps the ascii file format so you can try this and see. The delete needs to be an envelope around the insert so you get ^AD 3 ^AI 1 this is the first line in the first version. ^AE 1 ^AE 3 ^AI 2 this is the line that was added in the second version ^AE 2 That whole weave thing is really cool. The only person outside of BK land that got it was Br…

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.

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

#223

Post by ryao »

rbanffy wrote: post #209
Annatar wrote: post #207

Earlier quoted context omitted.

You again! (:-) You know that the VHDL code for UltraSPARC T1 and T2 has been open sourced? If I had enough knowledge about synthesizing code inside of an FPGA, I would be building my own SPARC-based servers like there is no tomorrow! As long as the code for those processors remains free, and a license to implement a SPARC ISA compliant processor only costs $50, the SPARC will never really, truly be gone, especially…

FPGA is not magic. SPARC implemented on FPGA will never be competitive with consumer-level x86's

Security wise, a FPGA is superior to consumer level x86 processors. How do you backdoor a FPGA?

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

#224

Post by aerique »

canadiangeek2 wrote: post #136
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…

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.

Just supporting big binary files in a hassle-free way would go a huge way to being better than Git and Gitlab.

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

#225

Post by masklinn »

paradite wrote: post #204

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

According to 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 `[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 `

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

#226

Post by ryao »

debaserab2 wrote: post #183
ryao wrote: post #170

Earlier quoted context omitted.

My remark was intended to cite how much farther bit keeper could have gone had it been open source from the start rather than belittle what bit keeper accomplished. At work, many of my newer colleagues have backgrounds in closed source software development. We are developing software that has no exact analog to existing software, and we hope that it will have a big impact. If it becomes as important as we think it co…

Except you're not Linus and you probably don't have a cult like following for any work you produce. Linus brought DVCS to the masses, but to pretend there wasn't more at play than simply open sourcing a project and hoping it all works out is complete rubbish. People have families to feed. Closed source is not inherently evil. It takes a unique situation to produce something like git that's product is beyond the sum o…

I wrote enough patches to ZFSOnLinux that I have the distinction of number 2 by commit count. It was a hobby for me at first and quite frankly, I never expected it to make a difference for more than a few hundred people. Now ZoL is on millions of systems through Ubuntu in part because of my work and there are far more places using it than I can count.

Open sourcing those patches rather than keeping them to myself made a difference that was greater than anything I imagined. Similarly, the impact of making ZFS open source far surpassed the expectations of the original team at Sun. I think that making any worthwhile piece of software open source will lead to adoption beyond the scope of what its authors envisioned. All it takes is people looking for something better than what previously existed.

As for closed source being inherently evil (your words, not mine), how do you fix bugs in closed source software that a vendor is not willing to fix? How do you catch things like a hard coded password that gives root privileges? How do you know that the software is really as good as they say? It is far easier with open source software than with closed source software. Closed source software is a bad idea.

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

#227

Post by ryao »

aerique wrote: post #224
canadiangeek2 wrote: post #136

Earlier quoted context omitted.

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.

Just supporting big binary files in a hassle-free way would go a huge way to being better than Git and Gitlab.

What would you consider to be hassle-free?

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

#228

Post by paiasso »

luckydude wrote: post #32
to3m wrote: post #18

1 year ago: 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.

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…

There is plenty of people doing "lets turn opensource and blame the community if does not work" arround.

It's a good excuse to blame that opensource broke your business, and that opensource could not save you from dying...

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

#229

Post by ryao »

drostie wrote: post #110
anarazel wrote: post #104

Earlier quoted context omitted.

Maybe I'm a too long time user of git, but I really fail to see why git as of the last 5 years is any harder to explain than hg. Personally I think the branching in hg is pretty much broken; alone the fact that it's pretty much impossible to get rid of branches is horrible.

Because the diagrams for hg are very simple, there is a really simple way to do branching that obviously works and commits a relatively forgivable sin: just `cp -a` the folder. Now, I know that that's in essence an admission of defeat! I'm not pretending that it's anything less than that. However, this is also the easiest explanation of, and model for, branching that anyone has ever created. The explanation of branch…

> I'm really surprised that software developers aren't more the sort to really say "why am I doing this?" and to prefer systems which make it easier to answer those questions with pretty pictures.

The network effect should explain it.

That said, using pictures to answer questions is fairly sadistic when those asking them are blind. I know a blind developer and I never use pictures when talking to him in IRC.

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

#230

Post by ryao »

qwertyuiop924 wrote: post #212
luckydude wrote: post #123

Earlier quoted context omitted.

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

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?

Post reply on HN