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

281–290 of 309 posts

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

#281

Post by Frondo »

wyoung2 wrote: post #272
Frondo wrote: post #264

Earlier quoted context omitted.

Oh, I used Fossil as my only VCS for 3 or 4 years. On my biggest projects, I had a heavily tweaked ticketing system and probably a hundred wiki pages. My experience with Fossil wasn't a "well the defaults suck, next thing" kind of situation for me, I was pretty invested in it. I also ditched it all 3 or 4 years ago, so my memory's not great, but what got me about the ticketing was that, for whatever reason, I could n…

> I could not sit any non-technical user in front of it and have it make sense to them So name a bug tracker with equivalent or greater flexibility to Fossil's that non-technical users do understand. I've only used one bug tracker that's simpler than Fossil's, and that's because it had far fewer user-facing features. Every other bug tracker I've had to use requires some training once you get past the "submit ticket"…

I am happy that Fossil works well for you. I long ago stopped being interested in tweaking my version control system or living with "email is hard, let's move on" and I moved onto other things.

I still think the Fossil value proposition--one file with all your project ephemera--is a good one. It'd be neat if BitMover produce something similar, e.g. maybe not a file, maybe a directory, but same idea, etc.

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

#282

Post by stephenr »

nullnix wrote: post #214
luckydude wrote: post #125

Earlier quoted context omitted.

This is buried but in case anyone reads it, the real reason to open source BK is to show the world that SCM doesn't have to be as error prone or as complicated as Git. You need to understand how Git works to use it properly; BK is more like a car, you just get in and drive.

That metaphor... needs work. Cars need a considerable amount of training to learn to use safely, let alone correctly. I can hack C enough that I dream in it routinely, and due to the resulting brain damage found git intuitive from the start, but there is no way I'll ever learn to drive: it's just too hard.

> Cars need a considerable amount of training to learn to use safely, let alone correctly.

Significantly less training than is required to know the internals of how it operates though.

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

#283

Post by Annatar »

luckydude wrote: post #251
Annatar wrote: post #220

Earlier quoted context omitted.

> Great is a relative term. But, can you name an OS, especially a UNIX, that is better in the general case? By "general case", I mean, good for just about anything, even if there's something better for some niche or role. Also, take into account the world we live in: More computing happens on servers and phones than on desktops and laptops; and judge the OS based on how it's doing in those roles. Okay then, SmartOS.…

That was an awesome rant. You must work with Brian. Edit: Bryan Cantrill, spelled it wrong.

Nothing would make me happier professionally than to have the opportunity to work with Bryan (sadly, we've never met, although I did work in Silicon Valley for a while). For instance, those times when I wouldn't be writing C, I could finally have an orgy of AWK one-liners and somebody would appreciate it without me having to defend why I used AWK.

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

#284

Post by Annatar »

vidoc wrote: post #268
Annatar wrote: post #220

Earlier quoted context omitted.

> Great is a relative term. But, can you name an OS, especially a UNIX, that is better in the general case? By "general case", I mean, good for just about anything, even if there's something better for some niche or role. Also, take into account the world we live in: More computing happens on servers and phones than on desktops and laptops; and judge the OS based on how it's doing in those roles. Okay then, SmartOS.…

> It's like this: when I run SmartOS, it's like I'm gliding around in an ultramodern, powerful, economical mazda6 diesel (the 175 HP / 6 speed Euro sportwagon version); "Tout ce qui est excessif est insignifiant"

"Yeah Tenzin, I... still don't speak that."

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

#285

Post by pjakma »

rbanffy wrote: post #47
luckydude wrote: post #41

Earlier quoted context omitted.

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

> the companies acted in self interest Sun, could, at least, make a profit building workstations and servers and licensing chips. It's actually very sad they don't build those SPARC desktops anymore.

They do, sort of. Intel were using SPARC cores in at least one of their "Management Engine" devices in chipsets recently anyway. ;)

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

#286

Post by pjakma »

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

The problem is the number of people who are into Illumos and want a portable Unix server is insignificant. All products came with fixed overheads (e.g. cost of tooling to start production), which have to be divided over the likely customer base. Small customer base == each customer pays a bigger share of the fixed overheads.

Basically, you want something to suit you and a small number of other people, but you won't pay for the cost of having something that "tailor made". You will only pay for the high-volume, lower-cost, more general product. So... that's all you get.

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

#287

Post by vacri »

mwcampbell wrote: post #271
ryao wrote: post #229

Earlier quoted context omitted.

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

How did Git's network effect get started in the first place?

It was made specifically for managing the linux kernel, which has huge amounts of contributors all doing their thing in different parts.

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

#288

Post by qb45 »

drostie wrote: post #266
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 your first question: Yes, you can also `git checkout -b newbranch`, rather than stashing the changes and then stashing them into a new branch; I just tend to stash my changes whenever I see that there's updates on the parent repository. Call it a reflex. Of course, you can also commit your changes and then `git branch`, which sounds insane (that commit is also now on the master branch!) until you remember t…

> Call it a reflex.

PTSD? :) Use local topic branches for everything to avoid unpleasant surprise merges. Once you are ready to merge, pull the shared branch, merge/rebase onto that and push/submit/whatever.

I sometimes keep separate branch for each thing that I intend to become a master commit. This way I can use as many small and ugly commits and swearwords as I please and later squash them for publication after all bugs are ironed out.

This helps with remembering why particular commits look the way they do, especially in high latency code review environments where it can take days or weeks and several revisions to get something accepted.

> Git's problem was precisely "oh, we can't push to that repository because we might have to mess with the working copy without Bob's knowledge," and it's a totally unnecessary problem.

Actually Bob's working copy isn't modified, it's just that if his branch was allowed to suddenly stop matching his working copy, he would probably have some fun committing (not sure what exactly, never tried).

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

#289

Post by nullnix »

luckydude wrote: post #276
nullnix wrote: post #259

Earlier quoted context omitted.

Yeah, that's the problem; it's optimizing for the wrong thing. It speeds up blame at the expense of absolutely every other operation you ever need to carry out; the only thing which avoids reading (or, for checkins, writing) the whole file is a simple log. Blame is a relatively rare operation: its needs should not dominate the representation. The fact that the largest file you mention is frankly tiny shows why your p…

Give me a file that was slow and lets see how it is in BitKeeper. I bet you'll be impressed. 50K lines is not even 3x bigger than the file I mentioned. Which we check out in 20 milliseconds. As for optimizing blame, you are missing the point, it's not blame, it's merge, it's copy by reference rather than copy by value.

I'd do that if I was still working there. I can probably still get hold of a horror case but it'll take negotiation :)

(And yes, optimizing merge matters too, indeed it was a huge part of git's raison d'etre -- but, again, one usually merges with the stuff at the tip of tree: merging against something you did five years ago is rare, even if it's at a branch tip, and even rarer otherwise. Having to rewrite all the unmodified ancient stuff in the weave merely because of a merge at the tip seems wrong.)

(Now I'm tempted to go and import the Linux kernel or all of the GCC SVN repo into SCCS just to see how big the largest weave is. I have clearly gone insane from the summer heat. Stop me before I ci again!)

Post reply on HN