7 ms·

>and bitkeeper, now open source at bitkeeper.org And no one cares about it. For a reason. >Git has no file object, it versions the repo, not files. Which is

>and bitkeeper, now open source at bitkeeper.org And no one cares about it. For a reason. >Git has no file object, it versions the repo, not files. Which is the correct thing to do. >if you have a graph per file (like BitKeeper does). Which is insane to do because you're basically making things more complex than they need to be, which is why merging in git is not only SUBSTANTIALLY faster than nearly every SCM out there, it also works a good deal of the time without issue. >No file object means no create event record, no rename event recorded, no delete event recorded. Most people do not need these. If you're going to choose to use file GCA's for the reasons listed above then you better have a damn fucking good idea of how much these features are actually used, because the trade offs are ENORMOUS. > That's insanely slow in a big repo. And also not really done that often. So you know, good job choosing to optimize for things no one is going to use on an astoundingly consistent basis or even needs to be super duper speedy in the first place. >You all lost out on "the most sane and powerful" as a result. Your concerns are misplaced? Misdirected? Git does things a certain way and people use it because people were tired of SCM's that decided to fix problems no one really cared about, and then do the things that developers do care about very poorly. You actually demonstrated this pretty thoroughly in your own post while attempting to call ,presumably, bitkeeper "sane." >Calling it a sane and powerful source control tool is just not supported by the facts I'm sorry, feel free to tell every other developer in the world, including the ones that are involved in far more collaborative efforts than your work requires, that the tool they're using is just not sane. I guess being one of the most used SCM's in the world, on one of the biggest OS projects in the world aren't really relevant facts into how "sane" an SCM is. I guess that's totally why bitkeeper used to be sold and now is open source.

luckydude 9y ago
OK, enjoy Git then. Your claim about merging is false though, demonstrably. Picking a repo gca when you could have used a much closer file gca is better. BK does that and automerges, correctly, more frequently and is way way faster than Git. I've written two source management systems. I'm confident in my knowledge. Arguing with some random dude who thinks he knows more than me is not really fun. So go enjoy Git. Lots of people are too busy/whatever to know what they are missing, maybe that's you. It's not me, I kinda like my audit trail to be accurate. Even Linus admitted to me in my kitchen that Git's audit trail is lossy. But go enjoy Git, I'm glad it works for you. Knock yourself out.
- jayd16 9y ago
  So why do you think BitKeeper failed and git is current leader in popularity?
  - philipwhiuk 9y ago
    It was proprietary for ages.
    - jayd16 9y ago
      That doesn't really explain why perforce, and mercurial seem more popular, nor the lack of current buzz around the project. I could be wrong but I can't say the mind share is very high.
  - joesb 9y ago
    It was proprietary. Linus wrote Git. Fanboy followed.
  - deleted 9y ago
    [deleted]
- kadenshep 9y ago
  >BK does that and automerges, correctly, more frequently and is way way faster than Git. Demonstrate it. You said it was demonstrable so presumably your Totally Sane SCM project should have evidence to back this up. >Arguing with some random dude who thinks he knows more than me is not really fun. Why because you basically made a complete fool of yourself? >Even Linus admitted to me in my kitchen that Git's audit trail is lossy. You might describe it as FUZZY, but not "lossy." Nothing is being "lost." My random internet dude that is actually an insane assertion to make, especially the anecdote about Linus being in your god damn kitchen. Not that it really changes anything about the characteristics of any SCM and why people use it. >But go enjoy Git, I'm glad it works for you. Enjoy your dead project. Glad it could be surrounded by a graveyard of other Totally Sane (C) SCM's who are collectively responsible for an untold amount of wasted man hours and licensing fees.
Bromskloss 9y ago
> For a reason. For what reason?
- luckydude 9y ago
  We took too long to open source it, people didn't like it being closed source and used for the Linux kernel. RMS was hugely butthurt that we had the best system and all open source had was CVS and SVN. Whatever, it paid the bills nicely for almost 20 years.
  - kadenshep 9y ago
    >We took too long to open source it, people didn't like it being closed source and used for the Linux kernel. And for things like this: >I didn't want to do anything that even smelled of BK. Of course, part of my reason for that is that I didn't feel comfortable with a delta model at all (I wouldn't know where to start, and I hate how they always end up having different rules for "delta"ble and "non-delta"ble objects). [1] [1] http://lkml.iu.edu/hypermail/linux/kernel/0504.3/1588.html http://lkml.iu.edu/hypermail/linux/kernel/0504.3/1588.html
    - deleted 9y ago
      [deleted]
  - emmelaich 9y ago
    That plus poorer integration with popular IDEs/editors such as Eclipse. In fact popular IDEs / editors back then supported CVS, then SVN and pretty much nothing else. You'd be amazed (or not) how little technical superiority matters. Developers just want to click stuff and get back to developing. Which is not to denigrate git, which I love so much it hurts.
    - luckydude 9y ago
      Yeah, you are so right. We sucked at that.
swsieber 9y ago
People used git because it was a tool that solved some SCM headaches. People use it now because it solved some headaches and because of the network effect. I think Git won because it was superior to CVS and SVN. I don't think it won because it was better than BitKeeper, Fossil or Mercurial. Lastly, does anybody have experience with git merges and BitKeeper merges? You make it sound slow, but it also sounds like you've never used it.
- luckydude 9y ago
  You can go look at BK's merge alg, it's quite cool. And the basic implementation was done in about 20 minutes. And it is extremely fast. I should write up a blog post about it, it's pretty complicated to understand because to get it, you need to understand SCCS's interleaved delta format. If you understand that format, then imagine that you put a line number in front of each data line in the weave. Check out the GCA, local, and remote versions of the file with those line numbers prefixed. Now run a 3 way merge on that. All the complexity in smerge.c comes from dealing with the cases where that doesn't work, but man, it works great 99% of the time.
lokedhs 9y ago
Ice never used Bitkeeper so I can't say if the statements he made are true or not, but arguing that something is good juts because a lot of people use it is most definitely not a valid argument. The computing world is full of absolutely terrible technologies people keep using even though much better alternatives exist. At first I considered listing a few and then I realise that it's likely most readers are actually users of one of those, but I'm sure you can think of a lot.
- kadenshep 9y ago
  >but arguing that something is good juts because a lot of people use it is most definitely not a valid argument. Yeah, I've only worded it 50 different ways.

luckydude 9y ago

OK, enjoy Git then. Your claim about merging is false though, demonstrably. Picking a repo gca when you could have used a much closer file gca is better. BK does that and automerges, correctly, more frequently and is way way faster than Git. I've written two source management systems. I'm confident in my knowledge. Arguing with some random dude who thinks he knows more than me is not really fun. So go enjoy Git. Lots of people are too busy/whatever to know what they are missing, maybe that's you. It's not me, I kinda like my audit trail to be accurate. Even Linus admitted to me in my kitchen that Git's audit trail is lossy. But go enjoy Git, I'm glad it works for you. Knock yourself out.

jayd16 9y ago
So why do you think BitKeeper failed and git is current leader in popularity?
- philipwhiuk 9y ago
  It was proprietary for ages.
  - jayd16 9y ago
    That doesn't really explain why perforce, and mercurial seem more popular, nor the lack of current buzz around the project. I could be wrong but I can't say the mind share is very high.
- joesb 9y ago
  It was proprietary. Linus wrote Git. Fanboy followed.
- deleted 9y ago
  [deleted]
kadenshep 9y ago
>BK does that and automerges, correctly, more frequently and is way way faster than Git. Demonstrate it. You said it was demonstrable so presumably your Totally Sane SCM project should have evidence to back this up. >Arguing with some random dude who thinks he knows more than me is not really fun. Why because you basically made a complete fool of yourself? >Even Linus admitted to me in my kitchen that Git's audit trail is lossy. You might describe it as FUZZY, but not "lossy." Nothing is being "lost." My random internet dude that is actually an insane assertion to make, especially the anecdote about Linus being in your god damn kitchen. Not that it really changes anything about the characteristics of any SCM and why people use it. >But go enjoy Git, I'm glad it works for you. Enjoy your dead project. Glad it could be surrounded by a graveyard of other Totally Sane (C) SCM's who are collectively responsible for an untold amount of wasted man hours and licensing fees.

Bromskloss 9y ago

> For a reason. For what reason?

luckydude 9y ago
We took too long to open source it, people didn't like it being closed source and used for the Linux kernel. RMS was hugely butthurt that we had the best system and all open source had was CVS and SVN. Whatever, it paid the bills nicely for almost 20 years.
- kadenshep 9y ago
  >We took too long to open source it, people didn't like it being closed source and used for the Linux kernel. And for things like this: >I didn't want to do anything that even smelled of BK. Of course, part of my reason for that is that I didn't feel comfortable with a delta model at all (I wouldn't know where to start, and I hate how they always end up having different rules for "delta"ble and "non-delta"ble objects). [1] [1] http://lkml.iu.edu/hypermail/linux/kernel/0504.3/1588.html http://lkml.iu.edu/hypermail/linux/kernel/0504.3/1588.html
  - deleted 9y ago
    [deleted]
- emmelaich 9y ago
  That plus poorer integration with popular IDEs/editors such as Eclipse. In fact popular IDEs / editors back then supported CVS, then SVN and pretty much nothing else. You'd be amazed (or not) how little technical superiority matters. Developers just want to click stuff and get back to developing. Which is not to denigrate git, which I love so much it hurts.
  - luckydude 9y ago
    Yeah, you are so right. We sucked at that.

swsieber 9y ago

People used git because it was a tool that solved some SCM headaches. People use it now because it solved some headaches and because of the network effect. I think Git won because it was superior to CVS and SVN. I don't think it won because it was better than BitKeeper, Fossil or Mercurial. Lastly, does anybody have experience with git merges and BitKeeper merges? You make it sound slow, but it also sounds like you've never used it.

luckydude 9y ago
You can go look at BK's merge alg, it's quite cool. And the basic implementation was done in about 20 minutes. And it is extremely fast. I should write up a blog post about it, it's pretty complicated to understand because to get it, you need to understand SCCS's interleaved delta format. If you understand that format, then imagine that you put a line number in front of each data line in the weave. Check out the GCA, local, and remote versions of the file with those line numbers prefixed. Now run a 3 way merge on that. All the complexity in smerge.c comes from dealing with the cases where that doesn't work, but man, it works great 99% of the time.

lokedhs 9y ago

Ice never used Bitkeeper so I can't say if the statements he made are true or not, but arguing that something is good juts because a lot of people use it is most definitely not a valid argument. The computing world is full of absolutely terrible technologies people keep using even though much better alternatives exist. At first I considered listing a few and then I realise that it's likely most readers are actually users of one of those, but I'm sure you can think of a lot.

kadenshep 9y ago
>but arguing that something is good juts because a lot of people use it is most definitely not a valid argument. Yeah, I've only worded it 50 different ways.