Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sapling: A new source control system with Git-compatible client

engineering.fb.com

Post reply on HN
Print view View original

291–300 of 543 posts

Re: Sapling: A new source control system with Git-compatible client

#291

Post by arxanas »

lolive wrote: post #280

I am a bit lost. Most of the discussions seem to focus on micromanagement of commits in your local HEAD branch. I agree that the Git commands are pretty primitive (aka low-level). But eventually you can learn the good patterns and deal with that. For me, the big question is how to manage a monorepo (with zillion of branches) so you can express which set of branches are relevant to your current concern at time T: - fo…

Generally speaking, they simply don't use multiple branches on the central server. See https://trunkbaseddevelopment.com/

Re: Sapling: A new source control system with Git-compatible client

#292

Post by matheusmoreira »

jordigh wrote: post #110

Ah, there it is. I was wondering when this would happen. Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions fro…

> started to demand that the Mercurial project work the way that Facebook wanted

Seems to be a recurring pattern when people interact with open source communities. Why does it have to be like this? It's not just companies either...

Re: Sapling: A new source control system with Git-compatible client

#293

Post by xyzzy_plugh »

johannes1234321 wrote: post #221
sixstringtheory wrote: post #199

Earlier quoted context omitted.

Fair point, but it is not clear to me that Sapling is better than Git. I haven’t seen anything in its docs or in the comments here where I haven’t thought of a way to do it with Git. I wonder what the cost benefit analysis would be: how many developers hours have been expended building Sapling so far, vs a list of things it can do that Git cannot. And I guess it bears repeating that I’m interested in possibility and…

> where I haven’t thought of a way to do it with Git. With git one can do "everything" true, doesn't mean that I want to teach everybody first what a DAG is and how one can manipulate that using git commands, but want to have something simpler. And yeah, git became a lot better over the years, but the plumbing still shines through in many places with inconsistencies.

Understanding a DAG becomes fundamental very quickly when trying to understand how distributed version control works. I would argue the opposite, that the internals are actually very reasonable and generic but it's the porcelain that has made some poor UX choices.

Re: Sapling: A new source control system with Git-compatible client

#294

Post by xyzzy_plugh »

jedberg wrote: post #26

In the argument of monorepo vs not, the usual argument goes like this: - It's too hard to scale for a large monorepo! - Google does it just fine! - But I don't have access to Google's tools! So kudos to Meta for both solving the problem and making it available to others. It will be interesting to see how useable it is outside of Meta. I know for example that while Netflix open sourced a lot of tools, most of them wer…

But they haven't done that yet. This is just the CLI, the centralized monorepo bits aren't yet available.

Re: Sapling: A new source control system with Git-compatible client

#295

Post by arxanas »

xyzzy_plugh wrote: post #287

This serves a very weird niche. Reading through the docs, this seems just as complex to operate as git, but designed with less decentralized operations in mind. Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? Because GitHub pull requests are terrible? None of this makes any sense to me. > Local branch names are optional. As are they in git, just hang out with a detached HEAD.…

A lot of the important work is on back-end scaling for a centralized repository. Example: the segmented changelog allows answering merge-base queries in ~O(log n) time and very quickly in practice; these queries need to happen all the time as part of handling merges on the server-side. You get the front-end, a streamlined interface derived from Mercurial, for "free" as part of the open-sourcing.

Re: Sapling: A new source control system with Git-compatible client

#296

Post by bitexploder »

matheusmoreira wrote: post #292
jordigh wrote: post #110

Ah, there it is. I was wondering when this would happen. Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions fro…

> started to demand that the Mercurial project work the way that Facebook wanted Seems to be a recurring pattern when people interact with open source communities. Why does it have to be like this? It's not just companies either...

I have been using fossil for my own local projects. Super easy to set the fossil UI up behind nginx for small teams. Been enjoying it.

Re: Sapling: A new source control system with Git-compatible client

#297

Post by alwillis »

kyrra wrote: post #276
mitrandir77 wrote: post #183

Nobody commented on the web interface yet which I think it's one of our coolest features: https://sapling-scm.com/docs/addons/isl

I'm sort of amazed that git and mercurial haven't built something like that yet. Makes me a little sad that Facebook created a new scm instead of expanding mercurial to include features like this.

Facebook did contribute a lot to Mercurial back in the day; maybe not so much today.

Yes, this would be awesome for Mercurial.

Re: Sapling: A new source control system with Git-compatible client

#298

Post by xyzzy_plugh »

arxanas wrote: post #295
xyzzy_plugh wrote: post #287

This serves a very weird niche. Reading through the docs, this seems just as complex to operate as git, but designed with less decentralized operations in mind. Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? Because GitHub pull requests are terrible? None of this makes any sense to me. > Local branch names are optional. As are they in git, just hang out with a detached HEAD.…

A lot of the important work is on back-end scaling for a centralized repository. Example: the segmented changelog allows answering merge-base queries in ~O(log n) time and very quickly in practice; these queries need to happen all the time as part of handling merges on the server-side. You get the front-end, a streamlined interface derived from Mercurial, for "free" as part of the open-sourcing.

But this centralized repository isn't available yet, so I cannot evaluate it.

And the problems you describe aren't really relevant outside a monorepo or low-volume repositories, of which the vast majority of open source code falls in. I much prefer the ability to clone an entire repository and be able to make changes in a distributed manner.

If this is for companies who aspire to have Google or Meta scale problems then this sure is a weird way to advertise it.

Re: Sapling: A new source control system with Git-compatible client

#299

Post by bitexploder »

mdaniel wrote: post #264
glandium wrote: post #203

Earlier quoted context omitted.

From the build instructions for sapling: "It can be built by running make oss in the eden/scm directory"

Holy hell, did they manually recreate meson? a 1700 line setup.py ... https://github.com/facebook/sapling/blob/main/eden/scm/setup... It's a pet peeve of mine folks that use python subprocess as a replacement for bash because it takes special discipline to not eat stdout and stderr, or to correctly try:finally: to show the Proc details before the raise eats the variable

Use python doit system if you need what this setup.py is doing. Its a great task and build system.

Re: Sapling: A new source control system with Git-compatible client

#300

Post by ironfootnz »

martinvonz wrote: post #204
kbd wrote: post #122

Earlier quoted context omitted.

I'm glad you mentioned Jujutsu. Given that it's also a git-compatible SCM my first thought upon seeing this post was how Sapling and Jujutsu compare.

I think those two things that arxanas mentioned are the biggest differences (i.e. working-copy-as-commit and conflicts in commits). I haven't used Sapling, but I suspect Jujutsu has better support for moving commits (and parts of commits) around without touching the working copy. Sapling, on the other hand, has much better support very large repositories, since they've spent a lot of time on that over the years. We'r…

I see a few issues on their approach for working copy and log search. Let me try out and see if I'm right on my assumptions.
Post reply on HN