Comments 13
Сразу закапывать можно. Git свою задачу решает качественно, в новая тулза будет очередной малопопулярной альтернативной scm.
Странно, или статья не полная, или это фигня какая-то. У гита есть проблемы, как раз связанные с крупными проектами, особенно когда есть много модулей, зависящих от другого модуля. При этом сабмодули достаточно некрасивое решение от гита. Вот по смыслу, с такими заявлениями "чтобы они были высокомасштабируемыми и справлялись с обработкой миллионов файлов", как раз это и ждешь - возможность работать со сложными проектами, с большим числом версий и зависимостей от них, какой-то другой подход к организации всего этого. А тут какой-то булшит про то, что можно не все ветки качать, да add можно не писать, а сразу commit.
у git тоже есть гуй и undo. Полистал оф доку, преимущества над гитом несколько спорные, и объясняют всю эту историю тем, что старый добрый гит в огромной монорепе слишком уж тяжёл для понимания, поэтому делают новый UX для упрощения работы с такими проектами. Ну, посмотрим-с) Кстати, ему уже 10 лет по их словам. Видимо, решили заопенсорсить)
Первопричиной возникновения подобных проектов является не сложности с пониманием git, а скорость работы. https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable
Why build a new source control system?
Sapling began 10 years ago as an initiative to make our monorepo scale in the face of tremendous growth. Public source control systems were not, and still are not, capable of handling repositories of this size. Breaking up the repository was also out of the question, as it would mean losing monorepo’s benefits, such as simplified dependency management and the ability to make broad changes quickly. Instead, we decided to go all in and make our source control system scale.
Starting as an extension to the Mercurial open source project, it rapidly grew into a system of its own with new storage formats, wire protocols, algorithms, and behaviors. Our ambitions grew along with it, and we began thinking about how we could improve not only the scale but also the actual experience of using source control.
чтобы было понятнее, зачем появился новый cvs, почитайте про страдания fb с гитом, какие у них были с ним проблемы, как их пытались обойти. история легко гуглится.
похоже в fb решили таки решить проблему на корню.
зы
скажем прямо, проблемы fb с гитом не будут возникать у 99.9.. (тут еще некоторое количество 9) % разработчиков.
В таких системах интересно как устроен сервер. А новый cli к github скучен чуть более чем полностью. Для понимания истории взаимодействия гита и больших реп, вот древнее выступление Торвальдса перед сотрудниками гугла
Попробовал. Для работы конечно не подходит, но как глоток свежего воздуха после git.
Не очень понятно что делать с этим sl pr - на github уж точно, но и через reviewstack тоже пока не ясно
Не скажу за разработчиков Sapling, но исходя из своего опыта создания подобных систем, логика появления команды pr следующая.
Когда новая система сделана, она классная и быстрая, в ней можно создавать коммиты, возникает необходимость отправить эти коммиты в условный git, в котором, на данный момент, живут все остальные разработчики. И чтобы не грузить потенциальных пользователей излишними деталями сочленения двух систем, делается команда pr, которая берёт на себя всю работу.
Посмотрел сейчас в Sapling. Если сделать локальный коммит, то можно сделать sl push --to <remote-bookmark> , а потом открыть эту ветку в github и создать PR, а можно просто сделать sl pr submit, и эта команда всё сделает автоматически. Также она проставит связи между локальными коммитами и PR на github, так что в smartlog будут видны соответствующие ссылки.
Авторитет у Фейсбука уже не тот, поэтому можно надеяться, что это "кульное улучшение" они продавить уже не смогут.
Обзор новой системы контроля версий Sapling компании Meta*