Comments 25
А можете посоветовать что-то для кучи больших бинарных файлов разного плана ( документы, изображения, cad файлы итп)
и да нужно под винду и желательно юзерфрендли как tortoiseHG))))
А обзор «веток» происходит в простом файловом менеджере.
То есть когда мы хотим сделать новую фичу, то darcs создает нам "Новая папка(2)" куда копирует содержимое всей репы? Звучит как трата дискового пространства.
А если я поработал на одной машине, потом переместился в другую локацию и там хочу поработать на другую машину ну или кому-то дать поработать с веткой отдать, то как оно без веток будет жить?
Pijul упомянут, но так толком и не рассказали про него.
контроля версий не для программистов и даже скорее для не‑программистов
Не знаю откуда вы это взяли, но nest как бы явным образом демонстрирует насколько вы неправы.
Да, верно, создаётся Новая папка(2) с клоном. Если нужна, оставляется, если нет, удаляется. Дисковое пространство, конечно страдает, но снэпшот веток в.git тоже чего-то стоят, хоть и оптимизированы.
Pijul я не использовал, поэтому всë, что мог рассказать было почерпнуто из приведённых в статье блогов и видео-выступлений. Его состояние сейчас 1.0.0-beta, судя по репозитори ю, ведётся активная работа. А несколько последних заявленных issues, связанных с падением системы, склоняют меня остаться на вполне надëжном Darcs.
Автор программы активно и интересно выступает. Собственно, о намерении создать систему контроля версий не для программистов я узнал из его большой лекции 2023 года, ссылку на которую привёл в статье.
Думаю, что у обоих этих проектов есть будущее, но главное, они, вернее, разрабатываемая для них теория, могут повлиять на флагманов: git, hg и т. д.
Автор программы активно и интересно выступает. Собственно, о намерении создать систему контроля версий не для программистов я узнал из его большой лекции 2023 года, ссылку на которую привёл в статье.
Простите, не увидел в статье ссылки на видео - только pdfки с теорией, документацию по дарксу и гитхабные репы. Можно ссылку на лекцию?
То есть когда мы хотим сделать новую фичу, то darcs создает нам "Новая папка(2)" куда копирует содержимое всей репы? Звучит как трата дискового пространства.
Это не самая большая проблема, я бы даже сказал меньшая. Главная проблема - репозитории разные и сихронизировать их нужно по отдельности. В то время как в Git с использованием worktree репозиторий один и всегда синхронизирован.
Я пользуюсь ворктри постоянно и не совсем понимаю, что вы имеете ввиду под "репозиторий один и всегда синхронизирован." Если вы про то, что все деревья можно найти из одной репы - да можно. Но вот сабмодули в каждом дереве свои и полностью независимые, что неимоверно доставляет когда в репе много лфс в сабмодулях.
Гитовые ворктри как раз и есть аналог описанного воркфлоу, а мне это необходимо, что бы иметь отдельные билды для каждой ветки и не пересобирать их когда нужно переключаться между ветками.
Но описание этого математического чуда конечно куцае, никому новая система и нафиг не упёрлась если она не умеет всё то что гит + ещё что то сверху или как минимум делает это объективно лучше. Тема сабмодулей не раскрыта от слова совсем, рекомендованный воркфлоу не описан, механика клона не раскрыта (может оно софт линки использует для не измененных файлов и место не жрет почти), как оно дружит с большими файлами ни слова, характеристики производительности да кому они нужны. Ну и сравнение с гитом сами как нибудь делайте.
Статья в одном предложении - там крутая математика, но я её вам не расскажу, а вообще мне понравилась авторизация, в целом норм, но гуя нет, пользуюсь в личном проекте на емаксе.
Спасибо, но тема сисек не раскрыта.
репозиторий один и всегда синхронизирован
Worktree все также ссылаются на единую репу и можно пушить работать с одинаковыми ветками из разных папок и не страдать. Darcs/Pijul судя по описанию хранят все в одно большой репе только в смерженном состоянии.
Ну и кейс с wt вполне понятный - нужен почти одинаковый код, но разные окружения а ля скопилированные Release из двух разных веток или работа с интеграцией чего-нибудь тяжеловесная. Чудо VCS делают так всегда.
Я пользуюсь ворктри постоянно и не совсем понимаю, что вы имеете ввиду под "репозиторий один и всегда синхронизирован."
Есть такой юзкейс: вношу я новые изменения в одном репозитории (коммиты). Если второй репозиторий от него не зависит, то, чтобы увидеть в нем изменения от первого, я должен прогнать коммиты через сервер: push и fetch. В случае отдельного ворктри коммиты сразу же будут доступны во второй папке.
Но вот сабмодули в каждом дереве свои и полностью независимые, что неимоверно доставляет когда в репе много лфс в сабмодулях.
Да, сабмодули раньше их использовал, это боль, вроде в любом случае. Но сейчас у меня монорепы и на работе, и в pet проекте. Это удобно.
механика клона не раскрыта (может оно софт линки использует для не измененных файлов и место не жрет почти)
Если аккуратно вести историю, то физический размер репозитория как по мне не особо большая проблема (учитывая сколько сейчас весят игры, фильмы). Хотя большое количество коммитов уже может быть проблемой, т.к. это порождает тормоза. Правда не уверен, что darcs не будет тормозить на больших репозиториях (возможно об этом даже еще не задумывались).
Честно говоря, я так и не смог уловить основного посыла. К сожалению, сам ни я ни Darcs, ни Pijul не пользовался, поэтому сравнить их с гитом не могу, но из статьи выглядит так, будто главное их преимущество для автора заключается в невозможности создания веток. Для меня же отсутствие функций всегда считалось недостатком системы, а не преимуществом. Собственно, в чём вообще проблема веток в гите? Он же не заставляет их использовать, хотите линейную историю — пожалуйста, ведите линейно. Хотите ветку, но в отдельном каталоге — git worktree к вашим услугам.
Про merge/rebase тоже не понял: возможности этих операций зависят не от системы контроля версий, а от состава патчей. Если патч конфликтует, то от перехода с git на darcs этот патч не перестанет быть конфликтным. rebase — это просто переналожение патчей с опциональной сменой порядка, только в darcs наличие этой функции преподносится как преимущество, а в git — как недостаток. Почему — неясно.
Я вполне допускаю, что у darcs могут быть какие-то удобства (иначе его бы не придумывали), но, увы, из статьи я их так и не увидел.
Они более математические - а графы git, уж извините, не математика-с... /s
Если пытаться тщательно вчитываться в текст, то кажется, что у автора достаточно специфический юз-кейс - параллельная работа над одним проектом в куче веток. Возможно, это какие-то эксперименты в проекте, возможно, тупо незавершённая работа. Патчи приходится перекидывать из одной ветки в другую, обновлять и синхронизировать их туда-сюда. И ветки его подзадолбали.
Возможно, на это также накладывается специфика конкретных инструментов, которые автор использует. На это намекают фразы типа "после мучений с современной системой аутентификации GitHub" (аутентификация из emacs штоли?) и "ничего графического для просмотра репозитория особо и не нужно" (а что, для git это разве обязательно? я вот не знал даже!). Как это часто бывает, изъяны собственного эмпирического опыта легко спутать с фундаментальными проблемами бытия (коими они не являются).
Могу предположить, что даже в рамках того же git автор мог бы попробовать вести несколько локальных репозиториев вместо кучи веток в одной репе. Каждый эксперимент в своей отдельной папке. В каждом эксперименте одна рабочая master-ветка. Репы друг с другом синхронизируются только при необходимости. Ненужные эксперименты дропаются через удаление папки. Результат был бы таким же, что в превозносимом им darcs, и без каких-либо особых накладных расходов. Опять же, совершенно не обязательно жить на GitHub и страдать от нюансов его аутентификации, особенно в случае личных проектов.
Но что поделать, где мы были со своими советами в нужный момент? Время было упущено, автор перешёл на darcsи поведал об том нам. За что ему спасибо. Хотя лёгкий флёр недоумения после прочтения всё же остаётся, подтверждаю.
Если пытаться тщательно вчитываться в текст, то кажется, что у автора достаточно специфическийюз-кейс - параллельная работа над одним проектом в куче веток. Возможно, это какие-то эксперименты в проекте, возможно, тупо незавершённая работа. Патчи приходится перекидывать из одной ветки в другую, обновлять и синхронизировать их туда-сюда. И ветки его подзадолбали.
Звучит как идеальный кейс для использования git worktree. И, насколько понял из статьи, в darcs такая проблема как раз не решается, так как нужно создавать отдельные независимые репы на каждую ветку.
Я нигде не говорил о недостатках git. Это отличная система, показывающая свою полезность в огромных проектах и в частных задачах.
Мой интерес к этим двум системам вызван во-первых, их теоретической базой, которая гарантирует алгебраические свойства операций с репозиторием, а во-вторых, полнотой и минимализмом их функционала, который мне и нужен.
Мне кажется, что развитие теоретической базы сами по себе достаточно интересная и полезная вещь, достойная, упоминания. Никакой агитации в моём материале нет. Это личный опыт и обзор.
В том-то и дело, что статья не показывает этот самый личный опыт. Я ни в коем случае не обвиняю в агитации, частные случаи и субъективные впечатления тоже очень полезны. Мне хотелось бы расширить свой кругозор, узнать о других системах и о конкретных ситуациях, в которых эти системы справляются лучше гита (или просто оказываются субъективно удобнее). Но этой информации я так в статье и не нашёл. Всё написанное либо одинаково применимо и к гиту, и к darcs (но по какой-то причине делается вывод о преимуществе второго), либо попросту некорректно сформулировано.
Возьмём для примера теоретическую базу darcs. Она вам понравилась? Ну так расскажите нам, в чём её суть! Чем подход к патчам в darcs отличается от подхода в git? Вы говорите, что в darcs история — это цепочка патчей. Ну так и в гите это цепочка патчей. Да, я знаю, что если влезть в потроха, то выяснится, что каждый коммит гита хранит целые файлы, но это всё скрыто, и с точки зрения пользователя каждый коммит представляется набором различий, патчем. И эти патчи можно просматривать, переносить поверх других коммитов, переставлять местами, уничтожать, разделять, сливать воедино… Вы говорите, что имеется некая алгебра. Хорошо, но что эта алгебра описывает, что она доказывает и что эти доказательства дают нам как пользователям? Вы пишете, что обеспечивается обратимость и коммутативность патчей. Но это же свойства самих патчей, а не системы хранения. Ведь любой патч обратим просто по своей природе; а коммутативность зависит от конкретного содержимого патчей, от того, меняют ли разные патчи одни и те же куски файлов. Если не меняют, патчи коммутативны, если меняют, то нет. И это свойство сохраняется независимо от того, в какой системе мы их держим: в darcs, в git, svn, mercurial, или просто в виде цепочки patch-файлов на диске. Так в чём же тогда заключаются особенности подхода darcs?
Посмотрел, в pijul нет способа сделать merge. Отличная система контроля версий, поехали дальше.
Pijul была создана именно для того, чтобы делать merge, причём корректно и минимизируя конфликты автоматически.
Стандартный способ pijul pull сливает два репозитория, эквивалентен git merge + rebase.
Если нужны отдельные ветки (channels) то для их слияния используется команда pijul apply, позволяющая соединить два канала.
В системах Darcs и Pijul мерджинг не отдельная функция, а неотъемлемая и принципиальная часть базового функционирования. По существу, в них нет ничего, кроме merge, поэтому она не выносится в отдельную команду.
<Del>
А под какой операционкой вы работаете и пытались ли пользоваться TortoiseGit ?
Darcs и Pijul. Системы контроля версий для тех, кто любит математику и не любит деревья