8 ms·
Sapling: Source control that's user-friendly and scalable (2022)
- jauntywundrkind 2y ago(2022) What's new since? Where are we seeing some adoption? Any progress on: > When used with our Sapling-compatible server and virtual file system (we hope to open-source these in the future), Is there significant git/sapling adoption at Meta, or is mercurial/eden still the main thing folks use? It's a neat idea. The smartlog command being a top level entrance point to a subdirectory in a monorepo seems smart as heck, a fine start.
- OliverGilan 2y agoIs there any way to even use this today? I’ve been waiting for the server and file system components to be open sourced for a couple years now
- _sgianelli 2y agoI used it for the last year or two at a company where all of our source control was with github. It has bindings to interact with github (not sure about what else) that allowed me to use it locally without anyone else having to change their workflows/install anything. Granted, I was mostly using it for stacked pr management among a few other things and not really fully taking advantage of all of it.
- aseipp 2y agoYes, it uses Git as the default backend, so it's more or less just a different interface to a Git repository. Everyone today uses it this way. The server-side components have been open source, but not fully usable due to fb-only code. That's changing and you can in theory build a working OSS server now that works on mysql/s3, but it isn't supported yet.
- rPlayer6554 2y agoI'm glad they opened this for others to use. When I worked at FB the VScode plugin was so neat and easy to use!
- codethief 2y agoA friend of mine works at Meta and recently gave me an intro to Sapling. Since then I've caught myself several times in my day to day, realizing how useful Sapling would be in my work.
- mistrial9 2y agoisn't Meta like some kind of real-life "borg" setup, where you can participate only to the extent that you are documented and tracked while doing so? Isn't it obvious that American capital sees no internal constraint on their use of people's whole social identity and lives as products for their machines? Why would anyone depend on their Meta core without knowing this?
- szundi 2y agoSometimes they make mistakes haha
- wmf 2y agoPeople might be more interested in the public version of Sapling https://sapling-scm.com/ https://sapling-scm.com/ rather than a blog post from 2022.
- aseipp 2y agoTo be fair, the website has changed very little since OSS launch (when this blog post first came out) and almost all of the main points of the blog are still the same, and the selling points are the same, too. So, I think it's fine, but definitely the website is the next place to look, yes. Probably the biggest major changes in Sapling I can personally think of are the introduction of the experimental "Dotgit" mode (.git exists next to .sl) and that the server-side stuff has recently become more usable. But none of it is stable yet, so for users not much has changed (yet).
- whalesalad 2y agofacebook will do anything but use git
- DaiPlusPlus 2y agoWhy is that?
- keybored 2y agoAll of Big Tech companies use hive repos, I mean monorepos, and Git can’t cope out of the box with that (except maybe at Microsoft since they have some people working on that).
- jasonpeacock 2y agoAmazon doesn't use monorepos. But then different tooling had to be created to manage dependencies and performs builds. You either have a large monorepo with special tooling, or many repos with special tooling. Either way, if you're a large company then you have special tooling...
- hocuspocus 2y ago> All of Big Tech Define all? Because that looks more like maybe half to me, at best.
- keybored 2y ago* Half of all Big Tech.
- mhh__ 2y agogit can cope a lot better than some seem to realize. Obviously it chugs on a truly huge repo but this is genuinely enormous. Sapling if I'm not mistaken uses the same file structure as git.
- aseipp 2y ago
- mdaniel 2y agodiscussed at the time: https://news.ycombinator.com/item?id=33612410 https://news.ycombinator.com/item?id=33612410
- yellowapple 2y agoUnfortunately the default name for the command (sl) conflicts with a command-line tool that's essential for my workflow: https://github.com/mtoyoda/sl https://github.com/mtoyoda/sl
- harikb 2y ago:)
- paxys 2y agoSo...change it?
- hinkley 2y agoClick on the link.
- lordgrenville 2y agoIt also conflicts with the PowerShell built-in Set-Location (though I imagine that's a pretty small intersection of users...)
- meindnoch 2y agoI spent 1 hour tracking down a bug caused by this.
- yellowapple 2y agoNow that sounds like a fun story :)
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- Yasuraka 2y agoI've been waiting for the server-side of things to be open-sourced ever since this announcement. In the meantime, I've been enjoying jj/jujutsu (https://github.com/martinvonz/jj https://github.com/martinvonz/jj), which started as a 20% project and has been out (and developed) in the open ever since. An introduction by Chris Krycho for those familiar with some form of vcs: https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/essays/jj-init/ "Jujutsu brings to the table a few key concepts — none of which are themselves novel, but the combination of which is really nice to use in practice: Changes are distinct from revisions: an idea borrowed from Mercurial, but quite different from Git’s model. Conflicts are first-class items: an idea borrowed from Pijul and Darcs. The user interface is not only reasonable but actually really good: an idea borrowed from… literally every VCS other than Git."
- riedel 2y agoThanks, looks great. Found this comparison: https://martinvonz.github.io/jj/latest/sapling-comparison/ https://martinvonz.github.io/jj/latest/sapling-comparison/ Will try it for sure.
- eterps 2y agoAlso check out lazyjj: https://github.com/Cretezy/lazyjj https://github.com/Cretezy/lazyjj
- 0cf8612b2e1e 2y agoThe readme did not make it clear: does this have a TUI workflow for moving line chunks around? That is my one reluctance towards jj is that my (bad practices?) frequently have me touch a few different unrelated bits simultaneously (eg editing foo, but fix a typo in bar) which I use stage to iteratively commit. From the jj stuff I have read thus far, my workflow would be a bit clunky to adapt.
- steveklabnik 2y ago> frequently have me touch a few different unrelated bits simultaneously (eg editing foo, but fix a typo in bar) which I use stage to iteratively commit. From the jj stuff I have read thus far, my workflow would be a bit clunky to adapt. I do this too! I find it easier in jj than in git. I wrote out a lengthy thing about the "oh I found a typo" use case here: https://lobste.rs/s/yjqd6d/against_names#c_7yfw7g https://lobste.rs/s/yjqd6d/against_names#c_7yfw7g
- nathan_compton 2y agoI won't use any version control system that doesn't let me stage individual changes in files. Staging entire files at once is just wrong.
- FrancoisBosun 2y agoI use Sapling as my main driver. I can commit or revert individual hunks just fine.
- zzl0 2y agoWhile there is no staging area, the powerful "--interactive" option is used to select specific files or lines you want committed. Besides that, there are powerful "split" feature to split a commit into smaller commits or move changes between commits.
- aseipp 2y agoYou can do that with Sapling, in fact it's both very easy and conceptually more robust than Git because with Sapling you are just manipulating commits. Sapling also includes `sl web` which makes interactive commits, splitting, and rebasing a breeze. In Sapling, commits are easy to manipulate, so there's nearly no need for the staging area, unlike Git where the staging area is easy to manipulate but commits are unreasonably hard. You can stage temporary changes to your hearts desire with a slight mindset shift.
- breadwinner 2y agoSo the motivation behind this project primarily is humongous monorepos that git can't handle? Are such huge monorepos a good idea in the first place? The idea behind the monorepo is that you don't have to wait for changes in a dependency to integrate — as soon as the change is checked into the dependency it is available to you. But this also means it is easy for a commit into a dependency to break a lot of downstream projects as it is not possible for the person maintaining the dependency to test all the dependent projects, unless it is acceptable to rely solely on test automation. It would be better for the owners of the dependent projects to decide when to take the new version of the dependency, after thorough testing.
- MajimasEyepatch 2y agoBasically all of the big tech companies run on giant monorepos.
- jkaptur 2y agoThe idea is that it is acceptable to rely on test automation, and that teams should apply the "Beyonce Rule" - if you like it then you should've put a test on it.
- hinkley 2y agoIf your tests contain 100% of your requirements then you can rewrite the code. If not then you’re fucked.
- zeroonetwothree 2y agoTest coverage at Meta is pretty far off from this
- breadwinner 2y agoAnd that's true in most companies. So then the question is, how acceptable is it to cause a break in some dependent project by making a change in a dependency. That will depend on the company and the type of product. For a consumer product company like Meta this is probably ok, but for an enterprise company that makes mission-critical software it may be less ok.
- oftenwrong 2y agoSeems like an approach that is superficially similar in architecture to what Google uses: Piper <-> Mononoke CitC <-> EdenFS Obviously, the immense scale of these companies constrains the possible solutions. I would be interested to know what design decisions are different between them.
- zamalek 2y agoMy biggest issue with Juijitsu and Sapling (especially) is compatibility with a repo where nobody else uses these tools. Sapling's problem is pretty obvious: I would have to get others to use FBs merge stack tool and get that past security approval. JJ? I spent a day trying to rebase/merge from trunk into my PR branch and truly fucked it up in a way that I have never managed with plain old Git - Google results were pretty scarce and unhelpful. For Git, I `switch foo; rebase main; push --force-with-lease`, for JJ (apparently) I `rebase -b main -d foo` - great! How do I access the results of the rebase and update my PR branch? How do I force push that branch? It feels like the documentation is in the same place that Git was in during the early days - I assumes you are deeply familiar with the idiomatic workflow. The effort put into the migration guide is minimal[1]. /rant [1]: https://martinvonz.github.io/jj/latest/git-comparison/ https://martinvonz.github.io/jj/latest/git-comparison/
- steveklabnik 2y agoSorry you had a bad time with jj! > Google results were pretty scarce and unhelpful. This is true, the Discord is very active and helpful though: https://discord.gg/bKWAbtpH https://discord.gg/bKWAbtpH Discord isn't for everyone, but you can get help quickly. You can also ask questions as GitHub Discussions: https://github.com/martinvonz/jj/discussions https://github.com/martinvonz/jj/discussions > How do I access the results of the rebase and update my PR branch? So, one small difference between jj and git is that jj's branches don't move automatically if you add new changes on top of them. In the next jj release, "branches" will be renamed to "bookmarks" to kinda emphasize this difference, even though they're used for git interop. Additionally, there's some discussion about what making branches/bookmarks move like git branches move could mean, with an experimental setting to give that a try. With all of that said, when you rebased, it shouldn't have changed where the head of your branch was pointed to, so you shouldn't have needed to actually move anything here. This is a side effect of the change/commit distinction: the branch points to a change, so when you rebase your stuff, the commits will change, but the change will not. That means all you needed to do was... > How do I force push that branch? `jj git push` will force push all of your changes. > It feels like the documentation is in the same place that Git was in during the early days - I assumes you are deeply familiar with the idiomatic workflow. I agree that the documentation isn't in a super awesome place yet, but I think the cause is kind of the opposite: there isn't really one idiomatic workflow, but instead a few common ones, and a hesitation to demand that a specific workflow is idiomatic. That being said, I have an in-progress tutorial that I have been waiting for two recent changes to land (one being the branch -> bookmark rename, the other being a different rename (obslog -> evolog)), that is intended to land upstream once I'm done with it: https://steveklabnik.github.io/jujutsu-tutorial/ https://steveklabnik.github.io/jujutsu-tutorial/ After that, if I can keep finding the energy, I'd love to keep improving the documentation, but I have a lot less FOSS energy than I used to, so we'll see.
- dazzawazza 2y agoAny idea how it deals with binary files and locking of files? I can't find anything in the docs about it. I'm a gamedev and currently Perforce and Subversion are the best in this space (because of robust Binary and locking support).