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

201–210 of 309 posts

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

#201

Post by nullnix »

luckydude wrote: post #50
qwertyuiop924 wrote: post #44

Earlier quoted context omitted.

I though SCCS had the same problems as RCS. What did it do differently?

RCS is patch based, the most recent version is kept in clear text and the previous version is stored as a reverse patch and so on back to the first version. So getting the most recent version could be fast (it isn't) but the farther back you go in history the more time it takes. And branches are even worse, you have to patch backwards to the branch point and then forwards to the tip of the branch. SCCS is a "weave".…

I had... much too extensive experience both with SCCS weaves and with hacking them way back in the day; I even wrote something which sounds very like your smoosh, only I called it 'fuse'. However, I wrote 'fuse' as a side-effect of something else, 'fission', which split a shorter history out of an SCCS file by wholesale discarding of irrelevant, er, strands and of the history relating to them. I did this because the weave is utterly terrible as soon as you start recording anything which isn't plain text or which has many changes in each version, and we were recording multimegabyte binary files in it by uuencoding them first (yes, I know, the decision was made way above my pay grade by people who had no idea how terrible an idea it was).

Where RCS or indeed git would have handled this reasonably well (indeed the xdelta used for git packfiles would have eaten it for lunch with no trouble), in SCCS, or anything weave-based, it was an utter disaster. Every checkin doubled the number of weaves in the file, an exponential growth without end which soon led to multigigabyte files which xdelta could have represented as megabytes at most. Every one-byte addition or removal doubled up everything from that point on.

And here's where the terribleness of the 'every version takes the same time' decision becomes clear. In a version control system, you want the history of later versions (or of tips of branches) overwhelmingly often: anything that optimizes access time for things elsewhere in the history at the expense of this is the wrong decision.

When I left, years before someone more courageous than me transitioned the whole appalling mess to git, our largest file was 14GiB and took more than half an hour to check out.

The SCCS weave is terrible. (It's exactly as good a format as you'd expect for the time, since it is essentially an ed script with different characters. It was a sensible decision for back then, but we really should put the bloody thing out of its misery, and ours.)

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

#202

Post by cauterized »

riffraff wrote: post #189
jason_s wrote: post #155

Earlier quoted context omitted.

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

doesn't github support mercurial?

Nope, but Bitbucket does support git.

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

#203

Post by masklinn »

alexeiz wrote: post #173
drostie wrote: post #109

Earlier quoted context omitted.

Ahahahahahaha. You think that works! No. That fails with the following semi-helpful error message: remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match rem…

Why is it that some people get Git naturally and some experience a world of frustration trying to use it? I think the kind of problems you describe usually come up if you approach Git with a mindset formed by another SCM. They are typical for people who are proficient with, say, SVN and who try to use Git thinking that Git must work something like SVN. (I'm using SVN as just an example here; it could be any other SCM…

> Why is it that some people get Git naturally

The only people I've ever seen "get Git naturally" were developers starting from the implementation details and working their way up (#0)[0].

Everybody else either worked very hard at it(#1)[1] or just rote-learned a list of commands(#2) that pretty much do what they want from which they don't deviate lest the wrath of the Git Gods fall upon them and they have to call upon the resident (#1) or heavens forbid the resident (#0) who'll usually start by berating them for failing to understand the git storage model.

> Well, Git is nothing like SVN and you'll always be missing something if you try to understand Git through SVN concepts.

Mercurial is also nothing like SVN, the problem is not the underlying concepts and storage model, it's that Git's "high-level UI" is a giant abstraction leak so you can't make sense of Git without understanding the underlying concepts and storage model, while you can easily do so for SVN or Mercurial.

[0] because the porcelain sort of makes sense in the context of the plumbing aka the storage model and implementation details

[1] because the porcelain in isolation is an incoherent mess with garbage man pages

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

#204

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

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

#205

Post by qb45 »

drostie wrote: post #109
dsp1234 wrote: post #98

Earlier quoted context omitted.

"hey, can you branch the code to commit those changes and push them to the testing server? This thing's really cool and we don't mind playing with the alpha version, but we might scrap it all later." Are they talking about hg or git here. Because that flow in git is: git branch git checkout git commit git push The only thing that git adds to that workflow is that creating a new branch doesn't immediately move you ont…

Ahahahahahaha. You think that works! No. That fails with the following semi-helpful error message: remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match rem…

> 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 error message and hack away.

Isn't

  git checkout -b new_branch
  git commit -a
  git push
what you are looking for?

And as for the push problem:

1. You aren't going to encounter it in git when pushing a newly created branch, but yes, you then have to ssh in and check it out.

2. I wonder how Mercurial handles pushing to repository with uncommitted changes, does it just nuke them?

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

#206

Post by Annatar »

nickpsecurity wrote: post #75
rbanffy wrote: post #47

Earlier quoted context omitted.

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

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'm not walking around with my UNIX server in hand. Very much akin to Apple Computer's iPad Pro (or whatever they call it, I don't remember, nor is that really relevant).

But the most important point was, and still is, and always will be: it has to cost as much as the competition, or less. Sun Microsystems would just not accept that, no matter how much I tried to explain and reason with people there: "talk to the pricing committee". What does that even mean?!? Was the pricing committee composed of mute, deaf and blind people who were not capable of seeing that PC-buckets were eating Sun's lunch, or what?

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

#207

Post by Annatar »

nickpsecurity wrote: post #144
ryao wrote: post #143

Earlier quoted context omitted.

The problems were Sun's failure to recognize that cheap IBM PC clones would disrupt them like they disrupted mainframes and Sun not trying hard enough to overcome Wintel's network effect. Sun needed to die shrink old designs to get something that they could fabricate at low cost and compete on price. Such a thing would have canabalized Sun workstation sales, which might be why they never did it.

Could be. It's gone now, though.

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 not for those people capable of synthesizing their own FPGA's, or even building their own hardware.

Some people did exactly that, a while back. Too bad they didn't turn their designs into ready-to-buy servers.

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

#208

Post by rbanffy »

nickpsecurity wrote: post #75
rbanffy wrote: post #47

Earlier quoted context omitted.

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

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

High-end chips only need to compete with other high-end chips. And low-end SPARC will not take off now that x86 has taken over.

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

#209

Post by rbanffy »

Annatar wrote: post #207
nickpsecurity wrote: post #144

Earlier quoted context omitted.

Could be. It's gone now, though.

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

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

#210

Post by qwertyuiop924 »

SwellJoe wrote: post #115
qwertyuiop924 wrote: post #107

Earlier quoted context omitted.

Fair 'nuff. And no, I haven't used commercial UNIXes all that much, but I have experienced plenty of Linux's warts. I do agree with a lot of those points, but containers on Linux just aren't there, systemd is a mess that's going to get pushed in no matter what we say, and there are plenty of issues to be had, although the ladder is true of any UNIX. If you want to know what the rest of the issues are, just start goog…

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…

You know, I think you're right. You have a good point. Thanks.

And I'd love to have some real retro computers, but I've got no money, and most of the really interesting ones are from the UK. Ah well...

Post reply on HN