7 ms·

This is more a response to many of the comments here than to the article, offering a perspective of what value they might bring. I’ve spent about 35+ years in

This is more a response to many of the comments here than to the article, offering a perspective of what value they might bring. I’ve spent about 35+ years in and around version control / SCM, with half of that being part of the BitKeeper team, where my job was to think about sets, graphs, and weaves in the context of a team making commercial customers’ lives better along with benefit to open source world. If Git is good enough for you, know that it is not true for everybody. For some subset of that everybody, it’s worth paying to have that pain go away. And part of having that pain go away is being able to stay connected to all that is, to be enough of a superset of the current world, to not be better in an incompatible way. That’s what I see in the pictures Steve and team draw: world that interacts with Git in a way that is better for some willing to pay to have the pain go away. I agree nothing much is being said about the Non-Git Storage Engine. As I’ve spent half of my life in that world, I get it: secret sauce. I don’t expect much to be said for a while.

giveupyousuck 7d ago
[flagged]
sublinear 7d ago
Once again, what is that "pain" exactly?
- rbsmith 7d ago
  Depends on the industry and specifics of a company. Are they game developers with multiple sites? Is the customer a large company with a lot of vendor relationships using different systems? Are they a vendor of some customizable component used by many large companies? Is there a good integration with their bug tracking? Do they need to long term support of 25 years? Pain was in some part of their process that was constrained, maybe technical (workflow or integrations), maybe legal. If Git works well enough, great! If not, maybe a different system fits better[0]. [0] - https://www.inkandswitch.com/project/backstitch/ https://www.inkandswitch.com/project/backstitch/
  - ocodo 6d ago
    .... this is such a fantastically enlightening set of replies rbsmith. outstanding.
hn_submit 7d ago
> For some subset of that everybody, it’s worth paying to have that pain go away. I guess the question is: is that subset of people large enough to run a profit-making business on?
- rbsmith 7d ago
  If you don't know otherwise, then no. Version control has always been a small market, and with Git, it's harder, because that sweet spot has been removed. If you have some great reasons to say yes (Perforce, GitButler, ERSC) such as better technology targeting some industry, 2-way bridge to Git and connections in a market, then you wouldn't be listening to me.
nrr 7d ago
Oh, hey. Nice seeing you here. I appreciate your work blazing some interesting trails with graphs and weaves in distributed version control. (Though, I must admit that I'm still left sort of scratching my head at the concept in a bytestream-oriented world instead of in the record-oriented world where I have, say, a deck of JCL cards and for which record-level inclusions and exclusions make sense.) My criticism of TFA is grounded less in refusing to tell us about the secret sauce than it is, uh, not giving us anything at all technologically substantive to chew on, I guess. I can certainly use my imagination given my own experience in these particular salt mines, and I know that Steve and team are good for the technology, but I'm nonetheless wondering who is intended to be TFA's audience.
- rbsmith 7d ago
  > I'm still left sort of scratching my head at the concept in a bytestream-oriented world instead of in the record-oriented world where I have, say, a deck of JCL cards and for which record-level inclusions and exclusions make sense Long live CDC Update! > who is intended to be TFA's audience I got something from seeing that last diagram. True, I don't know what features that future work will bring, but see that what ever it is, they want to keep it mappable to Git. Staying mappable to Git is a tether that can limit or reward creativity. You posted before Steve's response[0]. Does that help? [0] https://news.ycombinator.com/item?id=49664978 https://news.ycombinator.com/item?id=49664978
  - nrr 7d ago
    > Long live CDC Update! Yes! It's one of those things I've carried over to bitty box distributed environments. > You posted before Steve's response[0]. Does that help? It does a little, yeah, but I'll admit that I still feel somewhat teased by it rather than properly informed. As I wrote, I'm close enough to the technical details of this problem that I'm able to use my imagination. I wouldn't be surprised if some of my own proposed designs mesh up with what Steve and co. are doing. I just want some more concrete messaging "from the horse's mouth," as it were, about what's being undertaken to mitigate shortcomings in Git's architecture for folks in the enterprise space of technology and procurement stripes alike who might find it an interesting contrast to GitHub Enterprise.
steveklabnik 7d ago
Thanks Rick! I realize this post is light on technical details. I expected this kind of reaction from HN, which is also fine. The goal here is more to share anything about what it is that we've been doing; a lot of people assumed that we were going to be coming out with a GitHub-style social coding forge for open source, and so on some level, this is us saying we're not going to be doing that. A lot of people also assumed we'd be focusing purely on jj, and so we wanted to make sure to talk about how we do care about git compatibility, even as we look to the future. We'll be talking more about things as time goes on, but rather than never posting anything, this is the start of us stretching our muscles and being more involved in the public conversation around the future of version control. We've been too quiet!

giveupyousuck 7d ago

[flagged]

sublinear 7d ago

Once again, what is that "pain" exactly?

rbsmith 7d ago
Depends on the industry and specifics of a company. Are they game developers with multiple sites? Is the customer a large company with a lot of vendor relationships using different systems? Are they a vendor of some customizable component used by many large companies? Is there a good integration with their bug tracking? Do they need to long term support of 25 years? Pain was in some part of their process that was constrained, maybe technical (workflow or integrations), maybe legal. If Git works well enough, great! If not, maybe a different system fits better[0]. [0] - https://www.inkandswitch.com/project/backstitch/ https://www.inkandswitch.com/project/backstitch/
- ocodo 6d ago
  .... this is such a fantastically enlightening set of replies rbsmith. outstanding.

hn_submit 7d ago

> For some subset of that everybody, it’s worth paying to have that pain go away. I guess the question is: is that subset of people large enough to run a profit-making business on?

rbsmith 7d ago
If you don't know otherwise, then no. Version control has always been a small market, and with Git, it's harder, because that sweet spot has been removed. If you have some great reasons to say yes (Perforce, GitButler, ERSC) such as better technology targeting some industry, 2-way bridge to Git and connections in a market, then you wouldn't be listening to me.

nrr 7d ago

Oh, hey. Nice seeing you here. I appreciate your work blazing some interesting trails with graphs and weaves in distributed version control. (Though, I must admit that I'm still left sort of scratching my head at the concept in a bytestream-oriented world instead of in the record-oriented world where I have, say, a deck of JCL cards and for which record-level inclusions and exclusions make sense.) My criticism of TFA is grounded less in refusing to tell us about the secret sauce than it is, uh, not giving us anything at all technologically substantive to chew on, I guess. I can certainly use my imagination given my own experience in these particular salt mines, and I know that Steve and team are good for the technology, but I'm nonetheless wondering who is intended to be TFA's audience.

rbsmith 7d ago
> I'm still left sort of scratching my head at the concept in a bytestream-oriented world instead of in the record-oriented world where I have, say, a deck of JCL cards and for which record-level inclusions and exclusions make sense Long live CDC Update! > who is intended to be TFA's audience I got something from seeing that last diagram. True, I don't know what features that future work will bring, but see that what ever it is, they want to keep it mappable to Git. Staying mappable to Git is a tether that can limit or reward creativity. You posted before Steve's response[0]. Does that help? [0] https://news.ycombinator.com/item?id=49664978 https://news.ycombinator.com/item?id=49664978
- nrr 7d ago
  > Long live CDC Update! Yes! It's one of those things I've carried over to bitty box distributed environments. > You posted before Steve's response[0]. Does that help? It does a little, yeah, but I'll admit that I still feel somewhat teased by it rather than properly informed. As I wrote, I'm close enough to the technical details of this problem that I'm able to use my imagination. I wouldn't be surprised if some of my own proposed designs mesh up with what Steve and co. are doing. I just want some more concrete messaging "from the horse's mouth," as it were, about what's being undertaken to mitigate shortcomings in Git's architecture for folks in the enterprise space of technology and procurement stripes alike who might find it an interesting contrast to GitHub Enterprise.

steveklabnik 7d ago

Thanks Rick! I realize this post is light on technical details. I expected this kind of reaction from HN, which is also fine. The goal here is more to share anything about what it is that we've been doing; a lot of people assumed that we were going to be coming out with a GitHub-style social coding forge for open source, and so on some level, this is us saying we're not going to be doing that. A lot of people also assumed we'd be focusing purely on jj, and so we wanted to make sure to talk about how we do care about git compatibility, even as we look to the future. We'll be talking more about things as time goes on, but rather than never posting anything, this is the start of us stretching our muscles and being more involved in the public conversation around the future of version control. We've been too quiet!