TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Sapling: Source control that's user-friendly and scalable (2022)

76 点作者 lordleft8 个月前

14 条评论

Yasuraka8 个月前
I&#x27;ve been waiting for the server-side of things to be open-sourced ever since this announcement.<p>In the meantime, I&#x27;ve been enjoying jj&#x2F;jujutsu (<a href="https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj">https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj</a>), which started as a 20% project and has been out (and developed) in the open ever since.<p>An introduction by Chris Krycho for those familiar with some form of vcs: <a href="https:&#x2F;&#x2F;v5.chriskrycho.com&#x2F;essays&#x2F;jj-init&#x2F;" rel="nofollow">https:&#x2F;&#x2F;v5.chriskrycho.com&#x2F;essays&#x2F;jj-init&#x2F;</a><p>&quot;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:<p>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.&quot;
评论 #41504024 未加载
评论 #41504356 未加载
评论 #41504290 未加载
评论 #41503558 未加载
评论 #41503188 未加载
yellowapple8 个月前
Unfortunately the default name for the command (sl) conflicts with a command-line tool that&#x27;s essential for my workflow: <a href="https:&#x2F;&#x2F;github.com&#x2F;mtoyoda&#x2F;sl">https:&#x2F;&#x2F;github.com&#x2F;mtoyoda&#x2F;sl</a>
评论 #41503397 未加载
评论 #41503821 未加载
评论 #41503172 未加载
评论 #41502932 未加载
wmf8 个月前
People might be more interested in the public version of Sapling <a href="https:&#x2F;&#x2F;sapling-scm.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sapling-scm.com&#x2F;</a> rather than a blog post from 2022.
评论 #41504047 未加载
zamalek8 个月前
My biggest issue with Juijitsu and Sapling (especially) is compatibility with a repo where nobody else uses these tools. Sapling&#x27;s problem is pretty obvious: I would have to get others to use FBs merge stack tool <i>and</i> get that past security approval.<p>JJ? I spent a day trying to rebase&#x2F;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].<p>&#x2F;rant<p>[1]: <a href="https:&#x2F;&#x2F;martinvonz.github.io&#x2F;jj&#x2F;latest&#x2F;git-comparison&#x2F;" rel="nofollow">https:&#x2F;&#x2F;martinvonz.github.io&#x2F;jj&#x2F;latest&#x2F;git-comparison&#x2F;</a>
评论 #41503946 未加载
评论 #41504265 未加载
评论 #41503973 未加载
jauntywundrkind8 个月前
(2022)<p>What&#x27;s new since? Where are we seeing some adoption? Any progress on:<p>&gt; <i>When used with our Sapling-compatible server and virtual file system (we hope to open-source these in the future),</i><p>Is there significant git&#x2F;sapling adoption at Meta, or is mercurial&#x2F;eden still the main thing folks use?<p>It&#x27;s a neat idea. The <i>smartlog</i> command being a top level entrance point to a subdirectory in a monorepo seems smart as heck, a fine start.
评论 #41502558 未加载
评论 #41502090 未加载
OliverGilan8 个月前
Is 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
评论 #41502802 未加载
评论 #41504167 未加载
nathan_compton8 个月前
I won&#x27;t use any version control system that doesn&#x27;t let me stage individual changes in files. Staging entire files at once is just wrong.
评论 #41504109 未加载
评论 #41503029 未加载
评论 #41503664 未加载
rPlayer65548 个月前
I&#x27;m glad they opened this for others to use. When I worked at FB the VScode plugin was so neat and easy to use!
mdaniel8 个月前
discussed at the time: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33612410">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33612410</a>
codethief8 个月前
A friend of mine works at Meta and recently gave me an intro to Sapling. Since then I&#x27;ve caught myself several times in my day to day, realizing how useful Sapling would be in my work.
评论 #41502179 未加载
oftenwrong8 个月前
Seems like an approach that is superficially similar in architecture to what Google uses:<p>Piper &lt;-&gt; Mononoke<p>CitC &lt;-&gt; EdenFS<p>Obviously, the immense scale of these companies constrains the possible solutions. I would be interested to know what design decisions are different between them.
dazzawazza8 个月前
Any idea how it deals with binary files and locking of files? I can&#x27;t find anything in the docs about it.<p>I&#x27;m a gamedev and currently Perforce and Subversion are the best in this space (because of robust Binary and locking support).
whalesalad8 个月前
facebook will do anything but use git
评论 #41503503 未加载
评论 #41502425 未加载
breadwinner8 个月前
So the motivation behind this project primarily is humongous monorepos that git can&#x27;t handle? Are such huge monorepos a good idea in the first place? The idea behind the monorepo is that you don&#x27;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.
评论 #41503385 未加载
评论 #41503091 未加载
评论 #41503098 未加载
评论 #41503470 未加载
评论 #41503678 未加载
评论 #41503082 未加载