LINUX.ORG.RU

Pijul 0.11

 , , ,


3

6

Вышла новая версия Pijul — свободной системы управления версиями, основанной на теории патчей и написанной на языке Rust.

Pijul развивает идеи Darcs — Pijul быстрее, лучше, в нём решена проблема экспоненциальной сложности слияния и поддерживаются ветки (для всех, кто спросил и еще спросит «чем оно лучше Git» - ссылка на FAQ)

Слово «Pijul» (произносится «пихуль») — это мексиканское названия Бороздчатоклювого ани, вида птиц семейства кукушковых, чьи особи совместно работают над строительством гнёзд.

Улучшения в версии 0.11:

  • Добавлено частичное клонирование подкаталогов: pijul clone --path и pijul pull --path. При этом скачиваются только те патчи, которые затрагивают указанный подкаталог.
  • Добавлен парсер ~/.ssh/config — теперь Pijul будет автоматически использовать настройки псевдонимов хостов, SSH-прокси, ключей и т. д.
  • Внутренняя архитектура переведена на использование библиотеки Tokio — де-факто стандарта для асинхронного программирования на языке Rust. Минус велосипеды, новичкам будет проще разобраться в коде Pijul.
  • Исправлено много мелких и две крупные ошибки. Одна из них приводила к падению производительности при использовании pijul record, другая в некоторых случаях приводила к изменении содержимого патчей и файлов после клонирования.

Для нужд Pijul автором также развиваются вспомогательные библиотеки:

  • Thrussh — реализация клиента и сервера SSH на языке Rust.
  • Pleingres — клиентская библиотека, реализующая сетевой протокол PostgreSQL на языке Rust.
  • Sanakirja — хранилище «ключ-значение» на языке Rust, основанное на B-деревьях и поддерживающее транзации (аналог LMDB). «Sanakirja» по-фински означает «словарь».

Автор также разрабатывает Pijul Nest — аналог GitHub на основе Pijul и Rust. К сожалению, Nest пока не является свободным проектом.

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

Добавлен парсер ~/.ssh/config — теперь Pijul будет автоматически использовать настройки псевдонимов хостов, SSH-прокси, ключей и т. д.

Разве это не должно работать на уровне "Thrussh — реализация клиента и сервера SSH на языке Rust"?

Круто было бы в двух словах рассказать чем оно лучше git.

micronekodesu ★★ ()

Чем оно лучше git? [2]

inb4 написано на Rust.

a1batross ★★★★★ ()

А тем, кому лень ходить по ссылкам расскажут «чем оно лучше git»?

А так новость интересная и понятная — единственное что не понятно Чем оно лучше git?

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

Так же интересно понять: Чем оно лучше mercurial? Чем оно лучше svn? Чем оно лучше, прости господи, биткипер? И даже чем оно лучше cmz?

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

Чем оно лучше svn?

Оно распределенное. Внезапно.

Чем оно лучше, прости господи, биткипер?

А вот это интересный вопрос. Как минимум тем, что в основе Pijul лежит sound теория. Правда, не думаю, что тебе это интересно.

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

Теория безусловно интересна, только если она соответствует реальности. Какой реальности соответствует эта теория?

Evgueni ★★★★★ ()
Последнее исправление: Evgueni (всего исправлений: 1)

Чем оно годнее чем svn?

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

пихуль пихуль $text (commit) пихуль впихул (push) пихуль спихуль (pull)

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

Какой реальности соответствует эта теория?

реальности патчей

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

Как минимум тем, что в основе Pijul лежит sound теория. Правда, не думаю, что тебе это интересно.

я думаю, это будет интересно многим лоровцам.

anonymous ()

для всех, кто спросил и еще спросит «чем оно лучше Git» - ссылка на FAQ

Там нет ни одного аргумента чем оно лучше git.

Nest пока не является свободным проектом.

А вот и ответ. Нормально, чо, сделать несовместимый vendor lock in для неосиляторов гита и сразу тёпленьким впарить платный хостинг.

anonymous ()

Pijul развивает идеи Darcs

Для этого нужно быть написанным на илитарном ЯП и тихо скончаться никому не нужным.

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

О, несомненно. Проблема лишь в том на сколько та или иная теория правильно эту реальность описывает и насколько вы конкретно правильно эту реальность истолковываете.

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

Как минимум тем, что в основе Pijul лежит sound теория. Правда, не думаю, что тебе это интересно.

я думаю, это будет интересно многим лоровцам.

Ссылка есть выше. Вот, еще раз: https://pijul.org/model/ Оттуда : https://jneem.github.io/merging/

tailgunner ★★★★★ ()

Внутренняя архитектура переведена на использование библиотеки Tokio

Я очень надеюсь, что Tokio в итоге сдохнет и вместо него сделают что-то в три раза проще и в два раза легче.

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

В свое время Darcs был довольно популярен. Других Ъ-распределенных VCS тогда еще не было (ну, не считая SVK, но кто ж его помнит).

tailgunner ★★★★★ ()

Вот другой неадекват и неосилятор, автор fossil, сразу начал с интероперации с гит. Потому что даже он понимает что иначе нельзя. Тут таким даже не пахнет. Можно было бы списать на тестовый полигон для patch theory (которая фуфло на самом деле, ничего в vcs не привносящее, зато накладывающее ограничения из-за которых и возникла emp в darcs), но автор пилит какие-то костыли для чтения .ssh, следовательно надеется на какон-то реальное применение? Видимо, только им самим.

anonymous ()

В качестве преимуществ даркса и пихуля приводится следующий пример: https://tahoe-lafs.org/~zooko/badmerge/simple.html

В одной ветке кода меняем 1 строку. В другой добавляем несколько строк в начало, затем копипастим перед ними весь старый код. Затем объединяем ветки. Вопрос: в каком из копипащеных блоков менять строку — первом или втором? А может правильнее в обоих?

Даркс молча сменит во втором блоке. Пихуль, видимо, тоже. Автор исследования утверждает, что все остальные молча сменят в 1-ом, что неправильно (спорное утверждение, на мой взгляд). Мой небольшой опыт подсказывает, что в этом случае Git и SVN предложат пользователю разрулить конфликт вручную.

Как правильнее?

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

Как правильнее?

Ну, если это какой-нибудь bzero(), то лучше оставить в первом :D А вообще, лучше спросить юзера.

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

Даже по их FAQ не понятно, чем действительно оно лучше Git.

Утверждают, что в гите неправильно работают cherry-picking и иногда слияние параллельных веток. Это правда?

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

Под каким капотом? Где живут Си вместе с шеллом? Я, если что, говорю про то, на чем написан git.

Что плохого в C? Что плохого в shell? А то у меня в кроне запускаются шелл-скрипты. Мне нужно начинать волноваться?

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

Да всё нормально, пацаны, забудьте — я пошутил.

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

O'k. И каковы результаты?

Не знаю. Darcs был в основном юзабельным, но иногда начинал жрать как не в себя - Дэвид говорил, что с тех пор теория доработана. Но pijul-ом я не пользуюсь, так что ничего не могу сказать.

Пока я вижу:

К теории и проверке ее истинности Nest отношения не имеет.

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

Не вижу ничего печального. Ты хотел «в три раза проще» - тебе сделают async fn. Или к нему у тебя тоже претензии?

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

Не вижу ничего печального. Ты хотел «в три раза проще» - тебе сделают async fn. Или к нему у тебя тоже претензии?

Эээ... ты ведь в курсе, что весь async fn будет работать в контексте реактора? А единственный относительно рабочий реактор сейчас — Tokio?

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

git под капотом простой как два пальца.

Git «под капотом» нифига не простой. До минимальной юзабельности его доводили год-два. Причем всем миром.

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

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

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

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

Ну про идеальный это ты загнул, конечно.

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