LINUX.ORG.RU

Pijul 0.3

 , , ,


5

4

Состоялся первый публичный релиз системы управления версиями Pijul 0.3, написанной на языке программирования Rust. Pijul объединяет в себе производительность git и простоту использования darcs. Основанная на модели теории патчей, система Pijul направлена на то, чтобы сделать операции слияния и забора определенных коммитов (cherry-pick) более интуитивным.

Pijul можно установить при помощи Cargo (пакетного менеджера для Rust): команда cargo install pijul соберёт самую последнюю версию. Минимальная для сборки версия Rust — 1.15.1.

Примеры использования:

$ mkdir my_project
$ cd my_project
$ pijul init # создание нового пустого репозитория
$ echo " [ ] save the world" > todo.md # редактируем файл
$ pijul add todo.md # добавить todo.md: pijul начнёт отслеживать
                    # изменения в этом файле
$ pijul record # равнозначно 'git commit -p'
added file /home/florent/code/pijul/pijul/pijul/tuto/todo.md
Shall I record this change? [ynkad] y
+  [ ] save the world
Shall I record this change? [ynkad] y
What is your name <and email address>? Jean Doe <jean@example.org>
What is the name of this patch? Lest I forget
Recorded patch AeNEKi1-S60Pe_Hy__lbsyyKIrnkFvDBC-AOG4uUf0KxRG6v2pqwv…

Пример создания клона и внесения изменений; на этот раз команда record используется с ключом -a для сохранения всех изменений в отслеживаемых файлах. pijul record -m <сообщение> добавляет сопутствующее сообщение без необходимости открывания редактора, --author позволяет указать авторство, только для этого случая.

$ cd ..
$ pijul clone my_project clone_of_my_project
$ cd clone_of_my_project
$ echo " [ ] save the world, starting with the koalas" > todo.md
$ pijul record -am "Think of the koalas" --author koala_lover@example.au
Recorded patch ATqiYHQE528y0irRT4Oh0HEGbsR9e8J-7VMqUljUvsmduIcBU1YGdN_Abg…

Возвращаемся в исходный репозиторий и мерждим изменения:

$ cd ../my_project
$ pijul pull ../clone_of_my_project
Hash: ATqiYHQE528y0irRT4Oh0HEGbsR9e8J-7VMqUljUvsmduIcBU1YGdN_AbgpWZ7eaj-1q3dOA2OU5YYA1t1DY_T8
Authors: ["koala_lover@example.au"]
Timestamp 2017-03-16 16:50:49.059851279 UTC
  * Think of the koalas
Shall I pull this patch? [ynkad] y
 
$ cat todo.md 
 [ ] save the world, starting with the koalas

Pijul — пока очень молодой проект: разработчики сами только начали его использовать для разработки самого проекта Pijul.

Проект назван в честь ани — вида южноамериканских птиц, которые часто живут группами по четыре-пять особей. Они защищают свою территорию вместе, откладывают яйца в одно общее гнездо. Все члены группы насиживают их и заботятся о молодняке, даже молодые помогают заботиться о птенцах.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: sudopacman (всего исправлений: 5)

Проект назван в честь бороздчтатоклювого ани

В то время как на их сайте ни одной фотки птицы - только листья папоротника

SL_RU ★★★★
()

Вот мне не понятно, зачем в каждой новой системе контроля версий придумывать свои названия для команд. Чем commit не угодил, почему обязательно record?

vzzo ★★★
()
Ответ на: комментарий от SL_RU

Кто-нить меркуриал сейчас юзает?

Да.

Он живой вообще там?

Да. Релизы выходят, список рассылки разработчиков даже активнее, чем раньше.

tailgunner ★★★★★
()
Ответ на: комментарий от SL_RU

я использую. вполне себе живой, минорный релиз ежеквартально

littlechris ★★★
()

новая система управления версиями
новая

Оно же вроде с 2015 шевелится, только переписали на rust недавно.

xaizek ★★★★★
()
Ответ на: комментарий от clover

о, секта свидетелей доказательства перебором. валите скорее.

littlechris ★★★
()

Pijul 0.3 — новая система управления версиями

Нельзя впихнуть невпихуемое.

h578b1bde ★☆
()

Пихуль. Можно так коммиты называть.

thesis ★★★★★
()

Зачем оно нужно если есть mercurial? Почему это сравнивают с git, а не похожим mercurial?

anonymous
()

простоту использования darcs

Может мне кто-нибудь на пальцах объяснить в чём конкретно заключается простота использования darcs по сравнению с git'ом.

Я вот, наоборот, после «корпоративных» perforce'ов и tfs'ов, нашел GIT чрезвычайно простым и минималистичным. Чем тот-же самый darcs проще гита ? «Теория патчей» какое-то волшебство что-ли позволяет творить на которое git не способен ?

DawnCaster ★★
()
Ответ на: комментарий от tcler

Пока не настало время всем дружно играть на ржавом тромбоне - все окей, жить можно

Pinkbyte ★★★★★
()
Ответ на: комментарий от DawnCaster

Может мне кто-нибудь на пальцах объяснить в чём конкретно заключается простота использования darcs по сравнению с git'ом.

У git наркоманское устройство. Какие-то снепшоты вместо diff-ов.

Ещё, если я сначала модифицировал файл A, а потом B, я не могу вытащить изменения для файла B, не трогая файл A. Логика в подобных ограничениях ноль.

utf8nowhere ★★★
()

Pijul объединяет в себе производительность git и простоту использования darcs

было бы неплохо какой-нибудь пруф добавить; может прикручивается конвертер из darcs? взять какой-нибудь проект покрупнее и сравнить

anonymous
()

Основанный на модели теории патчей

Выучил теоркат только для того, чтобы прочитать статью. Но так и не нашёл времени прочитать. Лол.

anonymous
()
Ответ на: комментарий от utf8nowhere

Ещё, если я сначала модифицировал файл A, а потом B, я не могу вытащить изменения для файла B

git diff -- path/to/file/b уже отменили?

Для уже закоммиченного - git show [commit] -- path/to/file/b

Если commit не указан - будет выбран HEAD

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

Очевидно, мне нужно, чтобы истории остались совместимы. Не думал, что подобное кому-то придётся явно пояснять.

utf8nowhere ★★★
()
Ответ на: комментарий от utf8nowhere

Очевидно, мне нужно, чтобы истории остались совместимы

Поясни что ты имеешь в виду под этой фразой

Ты хочешь одинакового diff-а для одного файла и для нескольких? Как ты себе это представляешь?

Если коммит изменяет 2 файла, то выборка diff-ов по одному приведет в окончательном итоге к абсолютно такому же изменению.

Про тот факт что в git можно достать ЧАСТИЧНЫЙ diff чтобы его закоммитить, не тронув другие изменения в файле(хотя вот эта фича - воистину наркоманская!) - я промолчу

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 3)
Ответ на: комментарий от SL_RU

Кто-нить меркуриал сейчас юзает? Он живой вообще там?

Я юзаю активно. Я Git так и не осилил. Не смотря на 85+ собственных репозиториев на GitHub, каждая нестандартная операция у меня с ним превращается в длительное выяснение отношений. А Mercurial просто работает, я его вообще не замечаю обычно :)

KRoN73 ★★★★★
()

Пихуль - хорошее название. Сразу понятно, куда код запихивать. А так только SVN, только хардкор! Ибо он прост как пробка и без лишних свистоперделок.

anonymous
()
Ответ на: комментарий от utf8nowhere

Вообще, выглядит интересно. Но... Что-то я не вижу большого преимущества с тем-же гитом и его «состояниями». Да и визуализация истории большого проекта будет смотреться не особо.

Если на видео та самая теория патчей показана, то возникают вопросы - как объединить в один «узел» в истории - сразу несколько связанных изменений (а в программировании такое бывает сплошь и рядом) ? Если такой функционал есть - чем он лучше состояний в гите ? Ведь как я понимаю, «состояние» которым оперирует гит, это именно фиксация связанных изменений в проекте (а те кто коммитят кучу логически несвязанного говна в один коммит - будут страдать в независимости от VCS)

DawnCaster ★★
()
Ответ на: комментарий от Kilte

Ага набирать долго. Вангую успех VСS, которая по умолчанию будет предоставлять команду из 2 букв (и не надо тут мне про алиасы расказывать).

KennyMinigun ★★★★★
()
Ответ на: комментарий от DawnCaster

Если на видео та самая теория патчей показана

Нет, это видео про camp, родственника darcs. Но это неважно, виде демонстрирует функциональность darcs/camp/pijul, а не теорию, на которых они основаны.

Что-то я не вижу большого преимущества с тем-же гитом и его «состояниями».

Чем меньше искусственных ограничений — тем лучше.

utf8nowhere ★★★
()
Ответ на: комментарий от utf8nowhere

Тут дело не в ограничениях. А в том, что VCS берёт на себя обязанность разработчика по определению того какие изменения с чем связаны. С одной стороны это вроде и хорошо, но с другой не особо - VCS не сможет быть умнее разработчика чтобы определить что от чего зависит. С гитом, я сам себе злобный буратино когда коммичу - есть четкая последовательность изменений и ветвлений содержащая связанные изменения - и всем этим управляет разработчик. Я не уверен что все эти модномолодёжные чудо-VCS смогут правильно определить «контекст» всех изменений в более-менее крупном проекте сложнее пары файлов из того примера на видео, и что на выходе мы вместо внятной истории изменений не получим лапшу из логически несвязанных обрывков кода.

DawnCaster ★★
()
Ответ на: комментарий от utf8nowhere

В комментах к видео дело говорят.

anonymous
()

Что ещё за пихуйль и куда мне его запихуйливать? Чем это лучше git? (И что ещё за darcs, который упоминается?)

DELIRIUM ☆☆☆☆☆
()
Последнее исправление: DELIRIUM (всего исправлений: 2)
Ответ на: комментарий от DawnCaster

А в том, что VCS берёт на себя обязанность разработчика по определению того какие изменения с чем связаны. С одной стороны это вроде и хорошо, но с другой не особо - VCS не сможет быть умнее разработчика чтобы определить что от чего зависит.

Так если git не может быть умнее разработчика, зачем он определяет, что коммиты зависят друг от друга только потому, что один был сделан позже другого?

utf8nowhere ★★★
()
Ответ на: комментарий от utf8nowhere

зачем он определяет, что коммиты зависят друг от друга только потому, что один был сделан позже другого?

Он вовсе не по дате определяет что от чего зависит, дату можно любую проставить если хотите. Он определяет связанность коммитов по последовательности их создания, в рамках выбранной ветки. И в этом-то как раз есть логика - при реализации определённых фич, создаются ветки в которых находятся логически связанные изменения расположенные в порядке их сохранения в виде коммитов.

Гит тут ничем не ограничивает. Деление на «состояния» (коммиты) и их родителей-потомков нужно не гиту а разработчику для группировки связанных изменений. А эти самые дарксы, пихули и прочие хипсторские поделки как я понимаю сами определяют что от чего зависит и клепают историю самостоятельно. Видимо, чтобы мейнтейнеры принимающие мержи повесились.

DawnCaster ★★
()
Ответ на: комментарий от utf8nowhere

Честно говоря, в упор не вижу где там гит пытается быть умнее разработчика. Хочешь - создавай на каждую фичу по ветке. Хочешь - не создавай. Хочешь - делай rabase при коммите, хочешь - не делай. Хочешь, запихивай все связанные коммиты при разработке твоей фичи при мерже в один коммит, а хочешь - присовывай всю ветку. Всё определяется исключительно договорённостями в команде разработчиков. Куда ещё свободнее - я не пойму.

Это как раз тот самый Pijul, Darcs, Camp пытается быть умнее разработчика, создавая историю логической связности изменений ЗА РАЗРАБОТЧИКА.

DawnCaster ★★
()

теории патчей

Яйцеголовые жертвы высшего образования. Сделали клон популярного инструмента, который задолбает разработчика своими [ynkad] уже после 10-го патча. Зато у них есть крутая теория. Какую задачу решают сами не знают, зато свой велосипед.

Надеюсь, такие бывают только в ВУЗах, госконторах и пишут свои хобби-проекты, т.е. в нормальной коммерческой конторе с ними не придется общаться.

anonymous
()
Ответ на: комментарий от SL_RU

В то время как на их сайте ни одной фотки птицы - только листья папоротника

Птицы, узнав, чем им придется заниматься вместо высиживания яиц - разбежались (или разлетелись).

anonymous
()
Ответ на: комментарий от anonymous

Да вообще дебилы — пилят и пилят всякое, нет бы взять гит да делом заняться.

littlechris ★★★
()
Ответ на: комментарий от utf8nowhere

Ещё, если я сначала модифицировал файл A, а потом B, я не могу вытащить изменения для файла B, не трогая файл A.

Попробуй

git diff file_name

anonymous
()
Ответ на: комментарий от anonymous

который задолбает разработчика своими [ynkad] уже после 10-го патча.

для этого есть опция -a

dotcoder ★★★★★
() автор топика
Ответ на: комментарий от utf8nowhere

Во-первых, нафига хранить diff'ы? Чтобы дольше их накатывать при любом перемещении по истории и всё равно хранить снапшоты чтобы не совсем уж тормозило? Во-вторых, какое тебе дело диффы у него под капотом или снимки? Работа с VCS не зависит от того как у неё кишки устроены. Я долгое время был уверен что git хранит как раз diff'ы. В третьих, диффы он таки действительно хранит, только другие. Потому что pack'и жмутся дельта компрессией.

anonymous
()

Смешно. Даже у урода fossil и то фичи есть типа полного self-hosted, а у этих альтернативно одарённых вместе с darcs на двоих вообще ничего нет кроме профанации под названием теория патчей. Дальше хранения собственных исходников им и не взлететь.

anonymous
()
Ответ на: комментарий от DawnCaster

«Теория патчей» какое-то волшебство что-ли позволяет творить на которое git не способен ?

Да.

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonymous

Яйцеголовые жертвы высшего образования.

Сказал птушник и пошел строчить похапе код для компании «Roga und Kopyta».

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.