Назад в мезозой к программным динозаврам вместе с системой контроля версий Fossil

Несмотря на обилие существующих систем управления версиями (Version control systems), сквозь асфальт устоявшихся DVCS пробиваются время от времени новые и свежие поделки попытки. DVCS всё пилят и пилят, а серебряной пули как не было, так и нет: у одной системы - бинарные патчи, у другой - нет симметричного push, третья написана на питоне, и, хотя это наименьшее из зол, проблемы из-за наличия другой версии питона не радуют.

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


Почему Fossil?
Потому, что он имеет несколько killer-features, которых нет у конкурентов:

  • все данные хранятся в одном файле, который представляет собой SQLite базу данных, так что файлы не повредятся, если кто-то перенесёт данные на флешке с FAT;
  • написан на канонiчном C и представляет собой один-единственный экзешникисполнимый файл;
  • wiki, ticket system и графический интерфейс в одном флаконе (здесь привет всем сразу);
  • нормальный, человеческий симметричный push и pull (авторам git на этом месте предлагается удавиться);
  • имеет адекватную документацию и в меру человеческий интерфейс;
  • атомарные коммиты и параноидальная проверка целостности данных перед коммитом.
В общем, это то, о чём так долго мечтали белые, красные, зелёные, и даже голубые! Более того, если у вас есть опыт работы с SVN или Mercurial, вы почувствуете себя почти что дома - только некоторые приёмы работы будут вас, скажем так, удивлять. Но и это в большинстве своём настраивается по вкусу.


Установка Fossil
Установить Fossil очень просто: идём на сайт программы, выбираем сборку для своей операционной системы, и скачиваем единственный исполнимый файл.

Далее распаковываем архив, получаем файл fossil
Копируем этот файл по вкусу, например в /usr/local/bin и всё, Fossil готов к работе.




Начало работы с Fossil

Fossil использует файл-репозиторий, который является базой данных SQLite, для хранения всех файлов и истории проекта внутри.

Создание репозитория
Для начала работы можно создать новый репозиторий:
fossil init mygtd.foss
или клонировать существующий:
fossil clone /mnt/flash/exthdd/data/mygtd.foss
Далее нам нужно открыть репозиторий - сделать check-out и заполучить локальные файлы для работы:

fossil open mygtd.foss
При этом в текущую директорию будут извлечены все файлы из базы данных и появится файл _FOSSIL_ В нём содержится, помимо прочего, то, что вы можете отменить, список переименованных файлов и расположение репозитория. Изменения, которые не были отправлены в репозиторий (commit) тоже отслеживаются в файле _FOSSIL_ поэтому если вы что-то изменили в файлах и пытаетесь закрыть репозиторий командой
fossil close mygtd.foss
то получите сообщение:
fossil: there are unsaved changes in the current checkout
Это напоминание о том, что надо сделать коммит.


Отправка изменений (commit) в репозиторий Fossil
Каждое важное изменение файлов следует отправлять в репозиторий, снабдив осмысленным комментарием:
fossil ci -m "added new ideas from Brainstorm"
и через некоторое время, после всех проверок коммита, получим сообщение:
New_Version: a17e00ea83545549fb542a6fb6916b28fda66c15
Здесь нужно заметить, что коммиты Fossil завязаны на текущее время, и он крайне не любит (в отличие от, скажем, HG), если часы показывают неправильное время:
fossil ci -m "minor"
выдаст предупреждение:
fs: ancestor check-in [f29b4f1ee8] (2012-02-28 01:20:15.195) is not older (clock skew?) Use -f to override.
То есть часы стоит синхронизировать хотя бы иногда.

И ещё, если что-то в исходниках изменится за время коммита (например, сработает автосохранение в текстовом редакторе для файла, который есть в репозитории), то Fossil откажется коммиттить с формулировкой:

fossil ci -m "WeeklyReview - adding new projects"
New_Version: ef74d0458c158277dd12213c2d675ad7397d84ed
fs: working checkout before and after commit does not match
и ничего отправлено в репозиторий не будет. Для того, чтобы решить проблему, нужно сохранить все изменения в файлах и закоммиттить снова.

 


Ускорение коммитов в Fossil
Коммиты в Fossil делаются по умолчанию очень долго по сравнению с Git/Hg/Subversion, из-за того, что выполняется очень много проверок. Это делается для того, чтобы была полная уверенность в целостности файлов в репозитории:
In addition to identifying all files in the check-in, a manifest also contains a check-in comment, the date and time when the check-in was established, who created the check-in, and links to other check-ins from which the current check-in is derived. There is also a couple of checksums used to verify the integrity of the check-in. And the whole manifest might be PGP clearsigned.[документация]
Это можно настроить с помощью параметра repo-cksum. По умолчанию эта опция включена ("on") и приводит к вычислению контрольной суммы по всем файлам при каждом коммите как двойная проверка правильности. Команда
fossil settings repo-cksum off
отключает эти проверки на больших хранилищах для повышения производительности. После этого коммиты пойдут намного быстрее.

Коммиты и окончания строк в Fossil
Если вы работаете в коллективе, где используются Windows/MacOS, вы можете получать при коммитах сообщения вида:
./Projects/Project-EmailsToWrite.tex contains CR/NL line endings; commit anyhow (yes/no/all)?all
Это не ошибка, а предупреждение. Дело в том, что в Windows в качестве признака конца строки используется комбинация CRNL, а в Unix - просто NL. При переносе файлов между разнородными системами могут возникать как просто неудобства (текст с NL в Windows "вытянется" в одну строчку, а заметка с CRNL в Unix будет содержать "мусор" в конце каждой строки), так и реальные проблемы (в Unix не будут работать скрипты с CRNL).

Если вы не хотите видеть такие предупреждения, их можно отключить в командной строке:
fossil settings crnl-glob '*'
или в графическом интерфейсе:
fossil ui
Далее идём в секцию admin, потом в settings. Ищем и находим опцию "crnl-glob", и ставим в поле звёздочку: *. Это позволит игнорировать все окончания строк в формате CR/NL.


Коммиты и автоматическая синхронизация в Fossil
Есть у нас, к примеру, удалённый репозиторий, с которым мы хотим синхронизовать свой текущий репозиторий или послать туда изменения. Таковым станет репозиторий, в который мы в последний раз отправляли или запрашивали изменения.

Проблема в том, что по умолчанию автоматическая синхронизация включена, и это попортит начинающему массу нервов. Fossil на коммите думает, что если вы что-то пнули (push) в другой репозиторий (например, на резервном харде) - всё, с ним надо синхронизоваться до конца жизни. Если удалённый репозиторий недоступен, то не только не получится синхронизоваться, но и, собственно, закоммитить изменения в локальный репозиторий:

fossil ci -m "erase unnecessary phonebooks"
получим:
Autosync: file:///mnt/flash/mmc/mygtd/mygtd
Bytes Cards Artifacts Deltas
Sent: 130 1 0 0
fs: server sends error: >repository does not exist or is in an unreadable directory: /mnt/flash/mmc/mygtd/mygtd>
Более того, синхронизация тоже обломится:
fossil sync mygtd
Bytes Cards Artifacts Deltas
Sent: 3575 75 0 0
Error: Database error: database is locked
UPDATE event SET mtime=(SELECT m1 FROM time_fudge WHERE mid=objid) WHERE objid IN (SELECT mid FROM time_fudge);DROP TABLE time_fudge;
Received: 197 1 0 0
Total network traffic: 2068 bytes sent, 347 bytes received
Как говорилось в одном анекдоте, слющий абыдна да? Но всё можно поправить лёгким и непринуждённым движением:

fossil setting autosync off
Не знаю, кому в голову пришло это ставить по умолчанию on, но этот кто-то делает такое зря.



Добавление, перемещение и удаление файлов в Fossil
Собственно, добавление файлов просто и логично:

fossil add References/Personal/*.text

и теперь они добавлены:

ADDED References/Personal/Link.text
ADDED References/Personal/LinkScience.text
Если вы не уверены, что добавлены все нужные файлы, можно посмотреть список файлов, которые не находятся в репозитории но есть в каталоге:
$ fossil extras
И вот что мы видим:
Brainstorm.tex~
Projects/Project-MyOrgSys-Fossil.tex.backup
Projects/Project-MyOrgSys-Fossil.tex~
Projects/actionsProject-SplinePlay.tex~
References/Personal/Link.text
References/Personal/Link.text~
References/Personal/LinkScience.text
References/Personal/LinkScience.text~
mygtd-2706199415843815819-in.http
mygtd-2706199415843815819-out.http
mygtd-shm
mygtd-wal
Красным помечены файлы, которых в репозитории нет, а в каталоге есть.


Перемещение файлов в Fossil
... реализовано немного заковыристо. Например:
fossil mv Projects/DONE/*AORTA*DM* Projects/
получаем:
RENAME Projects/DONE/Project-AORTADM.tex Projects/Project-AORTADM.tex
RENAME Projects/DONE/actionsProject-AORTADM.tex Projects/actionsProject-AORTADM.tex
и смотрим на статус репозитория - что случилось?

fossil status

repository: /home/latitude/docs/mygtd/mygtd
local-root: /home/latitude/docs/mygtd/
checkout: a17e00ea83545549fb542a6fb6916b28fda66c15 2012-02-16 23:09:39 UTC
parent: 323b6e0da110298f7754032845cd43c5a1e7c2c6 2012-02-16 11:13:33 UTC
tags: trunk
comment: new ideas from Brainstorm (user: beast)
EDITED Brainstorm.tex
MISSING Projects/Project-AORTADM.tex
EDITED Projects/Project-Blog-ZapiskiDebianshika.tex
EDITED Projects/Project-EmailsToWrite.tex
MISSING Projects/actionsProject-AORTADM.tex
EDITED Projects/actionsProject-DMmodelsReview.tex
Часть файлов "пропали" - и если попробовать закоммитить изменения:
fossil ci -m "adding more projects"
получим ошибку:
fossil: no such file: /home/latitude/docs/mygtd/Projects/Project-AORTADM.tex
А файлов-то и нет, вернее, репозиторий об этом не знает. Проблему решает обновление:

fossil update
и теперь:

latitude@dot:~/docs/mygtd$ fs up
UPDATE Projects/Project-AORTADM.tex
UPDATE Projects/actionsProject-AORTADM.tex
--------------
updated-to: a17e00ea83545549fb542a6fb6916b28fda66c15 2012-02-16 23:09:39 UTC
tags: trunk
comment: new ideas from Brainstorm (user: beast)
"fossil undo" is available to undo changes to the working checkout.
Всё, теперь файлы перемещены.


Перемещение файлов в Fossil: если в директории такой файл уже есть...
то пользователя ждёт сюрприз: затирать файлы, как Hg, Fossil не станет, даже если поставить ключ -force:
fossil mv -force Projects/*Alexandria* Projects/DONE/
на это мы получим маловразумительное:

RENAME Projects/Project-Alexandria.tex Projects/DONE/Project-Alexandria.tex
fs: SQLITE_CONSTRAINT: abort at 34 in [UPDATE vfile SET pathname='Projects/DONE/Project-Alexandria.tex' WHERE pathname='Projects/Project-Alexandria.tex' AND vid=1815]: columns pathname, vid are not unique
fs: columns pathname, vid are not unique
UPDATE vfile SET pathname='Projects/DONE/Project-Alexandria.tex' WHERE pathname='Projects/Project-Alexandria.tex' AND vid=1815

If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.
Вообще, отвлекаясь от темы: сообщения об ошибках Fossil это цирк с конями. Иногда кажется, что несколько марсиан из команды инопланетных захватчиков Git затесалось-таки в разработчики Fossil.

На самом деле это сообщение означает, что Fossil так не даёт затереть файлы, которые уже есть в другой директории. То есть если мы перемещаем файлы в другую директорию, а они там уже есть, нам выведут вот такое сообщение. Вариантом решения проблемы является предварительное затирание:
fs rm Projects/DONE/*Alexandria*
имеющегося файла, обновление:
fossil update
и последующий коммит, после чего перемещение станет работать.



Отправка (push) и запрос (pull) изменений в удалённые репозитории Fossil
Вот тут-то как раз всё очень просто: Fossil, в отличие от всяких git-ов, делает как раз то, что вы от него ждёте.

Запрос изменений из удалённого репозитория (pull)
Чтобы скачать изменения из удалённого репозитория, достаточно написать:

fossil pull
и мы получим:
Server: file:///mnt/flash/exthdd/fossil/mygtd
Bytes Cards Artifacts Deltas
Sent: 146 2 0 0
Received: 308 7 0 0
Total network traffic: 288 bytes sent, 410 bytes received
В данном случае изменений нет (подсвечено зелёным), но если бы они были (подсвечено красным):
Server: file:///mnt/flash/exthdd/fossil/mygtd
Bytes Cards Artifacts Deltas
Sent: 7914 9 1 4
Received: 308 7 0 0
Total network traffic: 4684 bytes sent, 411 bytes received
то надо обновить дерево исходников, чтобы их увидеть:
fossil update
Если удалённый репозиторий теперь в другом каталоге, придётся написать полный путь:
fossil pull /mnt/flash/exthdd/fossil/mygtd
чтобы получить изменения из репозитория /mnt/flash/exthdd/fossil/mygtd и после этого не забыть сделать fossil update.

Отправка изменений в удалённый репозиторий (push)
Как все нормальные люди привыкли, в Fossil имеется симметричный push, то есть возможность задудонить изменения в удалённый репозиторий, если на то хватает прав:
fossil push
и изменения будут отправлены в удалённый репозиторий:
Server: file:///mnt/flash/exthdd/fossil/mygtd
Bytes Cards Artifacts Deltas
Sent: 19013 13 2 4
Received: 32 1 0 0
Total network traffic: 7346 bytes sent, 244 bytes received
Всё, теперь удалённый репозиторий имеет те же изменения, что и у вас. На том конце следует сделать update и можно продолжать работать.

Но не всё так сказочно, и бывает, что мы пытаемся сделать push в репозиторий, в который у нас нет прав это делать. То есть права доступа там, скажем, только на чтение, и попытка пнуть (push) туда изменения:
fossil push /mnt/flash/exthdd/zips/mygtd_fossil/mygtd

будет неудачной:

Bytes Cards Artifacts Deltas
Sent: 176 2 0 0
fs: server sends error: >SQLITE_CANTOPEN: cannot open file at line 29653 of [54cc119811]>>SQLITE_CANTOPEN: os_unix.c:29653: (2) open(/mnt/flash/exthdd/zips/mygtd_fossil/mygtd-wal) - No such file or directory>>SQLITE_CANTOPEN: unable to open database file>>Database Error>
>unable to open database file
SELECT value FROM config WHERE name='allow-symlinks'>>If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.
>
Это вот так логично у fossil выглядит сообщение о том, что отправка изменений не удалась из-за отсутствия полномочий:
beast@notebeast:/mnt/flash/exthdd/zips/mygtd_fossil$ ls -l
итого 2136
-rw-r--r-- 1 1001 users 2183168 2012-02-13 17:49 mygtd
Не очень понятно, зачем Fossil закатывает такую истерику. Достаточно дать прав командой
chmod 777 /mnt/flash/exthdd/zips/mygtd_fossil
и всё проходит отлично.


Объединение изменений (merge) в Fossil

Если в удалённом репозитории и в вашей рабочей копии произошли изменения в одном и том же файле, или вы добавили какой-то файл локально, то вам предстоит объединение (merge). Процедура эта, как правило, не очень сложная, и таких лютых проблем как в Subversion (10 человек изменили 100 строк в одном файле, и посреди этого праздника его кто-то переименовал) не будет. Вместо этого будет создана новая ветка, и ей присвоен свой хэш. Например:

fossil merge b67775a562
имеем:

ADDED Projects/Project-UniGetIt.tex
ADDED Projects/actionsProject-Alexandria.tex
ADDED Projects/actionsProject-UniGetIt.tex
UPDATE 4myGTD.tex
UPDATE Brainstorm.tex
UPDATE List-Sometimes-Projects.tex
UPDATE Projects/Project-Alexandria.tex
UPDATE Projects/Project-Blog-ZapiskiDebianshika.tex
UPDATE Projects/Project-MediCare.tex
UPDATE Projects/Project-MyOrgSys-Fossil.tex
"fossil undo" is available to undo changes to the working checkout.
И всё, можно продолжать работу.



Удаление лишних файлов в Fossil
Иногда вы создаёте файлы в проекте и забываете их добавить в репозиторий - как проверить, какие файлы добавлены, а какие нет? В Mercurial, к примеру, это видно по команде hg status
У Fossil в этом отношении дело обстоит иначе: fossil status покажет только состояние файлов, которые уже есть в репозитории:
fossil status
и мы можем выяснить, какие файлы изменились (подсвечено зелёным):
repository: /home/beast/docs/mygtd/mygtd
local-root: /home/beast/docs/mygtd/
checkout: d22284b55e52d33ea1e0030a6aebb88523e10ea5 2012-02-19 08:59:01 UTC
parent: f37c24eb6611356c75f14cc64c2d20b5941cf6da 2012-02-19 08:30:55 UTC
tags: trunk
comment: writing post further (user: beast)
EDITED Projects/Project-MyOrgSys-Fossil.tex
EDITED Projects/actionsProject-MyOrgSys-Fossil.tex
EDITED Projects/actionsProject-MyOrgSys-Pomodoro.tex
Для поиска файлов, которых в репозитории нет, а в текущем дереве исходников (рабочий каталог) присутствуют, есть есть специальная команда

fossil extras
и теперь мы видим:
Brainstorm.tex~
Projects/Project-MyOrgSys-Fossil.tex.backup
Projects/Project-MyOrgSys-Fossil.tex~
Projects/actionsProject-SplinePlay.tex~
References/Personal/Link.text~
References/Personal/LinkScience.text~
mygtd-2706199415843815819-in.http
mygtd-2706199415843815819-out.http
mygtd-shm
mygtd-wal
Всё сплошь бекапы и лишние файлы, как бы их удалить все разом? На этот счёт у Fossil есть замечательная команда

fossil clean --force
Ключ force удалит все лишние файлы, не задавая никаких вопросов при этом.


Графический интерфейс: ticket system, Wiki и другие удобства
Собственно, это одна из главных возможностей (killer-feature). При этом нам не нужно подымать apache и прочую тяжёлую артиллерию - всё уже встроено в сам fossil. Всё, что нам потребуется - это броузер, в котором удобно просматривать сообщения об ошибках (Tickets), историю проекта (Timeline) и Wiki. Например, по команде
fossil ui
мы попадём на главную страницу проекта, которая может выглядеть вот так скромно:


Здесь же есть доступ к истории проекта (Timeline), списку файлов и возможности их просмотреть (Files), веткам кода (Branches), меткам (Tags), системе контроля ошибок (Bugtracking здесь называется Tickets), документации в виде Wiki (Wiki) и настройкам (Admin).

Графический интрефейс очень прост и быстро осваивается. Вот, например, как выглядит история коммитов в графическом интерфейсе:

Кроме этого, есть очень удобная система Tickets. То есть когда в коде проекта появляются ошибки, обычно пользуются сторонними сервисами (Trac или системой контроля ошибок на bitbucket). В случае с Trac это ещё одна программа, которую нужно устанавливать и конфигурировать. Сторонний сервис bitbucket может отвалиться без предупреждений. А в Fossil у вас всегда будет локальная копия, с которой можно работать всегда. Вот как выглядит типичное заведение Ticket:


Добавляем описание, степень критичности бага:


и всё, даём целительный пендаль автору:

Кроме того, есть ещё Wiki, которая тоже содержится прямо внутри проекта, а не на сторонних сервисах. Но для одного поста это уже, пожалуй, многовато.




Недостатки Fossil
Серебряной пули среди систем контроля версий нет, но с Fossil увеличивается надежда, что оная пуля таки появится. Конечно, проект молодой, и разработчики иногда действуют в ковбойском стиле "до основанья а затем". Пока что из минусов Fossil можно упомянуть:
  1. Очень медленная синхронизация репозиториев и коммитов.
  2. Слишком много мер предосторожности, и, как следствие, очень долгие коммиты.
  3. Дурные на всю голову сообщения об ошибках.
  4. Довольно топорная работа с ветками. Если вы создали Leaf и там что-то удалили, закрытие Leaf выйдет вам боком.
Но учитывая преимущества Fossil в виде графической веб-морды, баг-трекера и вики в одном флаконе с системой контроля версий, вариант с Fossil смотрится очень даже выигрышно.


Дополнительная информация и ссылки
Fossil Version Control A Users Guide
www.fossil-scm.org/schimpf-book/doc/tip/fossilbook.pdf
File Format: PDF/Adobe Acrobat - Quick View

37 комментариев: |высказаться!| RSS-лента дискуссии.|
post-factum комментирует...

> То есть когда в коде проекта появляются ошибки, обычно пользуются сторонними сервисами (Track или системой контроля ошибок на bitbucket). В случае с Track это ещё одна программа, которую нужно устанавливать и конфигурировать.

Наверное, таки не Track, а Trac.

Спасибо за статью. Интересно было почитать, но git я на него не променяю :).

iv_vl комментирует...

Спасибо за пост! Натолкнул на изучение несимметричности push/pull в Гите, решение вопроса здесь!

ice2heart комментирует...

Спасибо. Круто

Kostya комментирует...

Вы ещё не до конца умеете его готовить правильно!

Проблемы с synk возникают, потому что synk у вас не такой, как у нормальных людей. :P
Обычно синхронизируются с _удалённым_ репозитарием, куда нет доступа по nfs. Т.е. если удалённая репа будет по адресу http, то и коммиты будут проходить при ошибке синхронизации и сами ошибки будут внятные.
Хотя конечно это минус, что с локальными такая фигня (я это никогда не использовал и не знал).

Кроме того длительность коммитов возникает ещё и из-за хранения версий в дельтах, а не целиковых файлах. И потом у меня они всегда проходили максимум за 2-3 секунды (это большие изменения, мелкие около 1й) на проекте с 7-ю метрами чистых исходников.

Кстати, тикеты можно менять. Т.е. можно добавлять/удалять поля, правда для этого придётся немного разобраться, поскольку это делается не мышковозюкательно, а путём задания правильных шаблонов.

PS
Поправьте extra на extras, потому как именно так она называется в хелпе.

virens комментирует...

@post-factum комментирует...

Наверное, таки не Track, а Trac.
Да, очепятался. Исправлено.

Спасибо за статью. Интересно было почитать
Пожалуйста. Собственно, здесь я собрал настройки и приколы фоссила, которые я забываю.

но git я на него не променяю :)

Про Git у меня есть лирическое отступление. В пост вставлять его не стану, ибо холивар, а в комменты - запросто. Для разжигания дискуссии :-)

Лирическое отступление: почему не Git. Самое худшее в мире программного обеспечения - когда кто-то решает как вам должно быть удобно за вас. Это раздражает: теперь не вы подстраиваете программу под себя (как должно быть), а ломаете свои привычки из-за того, что кто-то в процессе дизайна курил какие-то экзотические шишки (что мы имеем в git, gimp, scilab, unity и прочих исчадиях софтостроения).

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

Я изменил одну строчку в одном файле, который есть в репозитории, и теперь хочу просто закоммитить изменения. Что я делаю в HG? Правильно:

hg ci -m "this is my changes"

Что я делаю в Git? Сначала я должен сделать git add изменённый файл, и только потом git commit. Но я же менял файл, который уже добавлен в репозиторий - git о нём уже знает, так какого же лешего нужно добавлять его снова!?

Далее. Нельзя сделать git push в чужой репозиторий просто так, без предварительного битья головой о стену, если у меня есть все права на это. Делаем git push и получаем в ответ:

“! [rejected] master -> master (non-fast forward)”

Ну и что всё это значит? А, оказывается, надо сначала сделать git pull. Гениально, но почему этого маразма нет в HG и Fossil? И нет, я не хочу тратить месяц на чтение документации Git чтобы коммитить свои изменения, объединять изменения (merge), посылать данные в удалённый и локальный репозитории (push / pull) - то, что я делал годами в Subversion и позднее в Hg и Fossil без всякого подобного геморроя.

Cистема контроля версий это инструмент, который должен помогать мне делать мою работу, а не путаться у меня под ногами и выкобениваться по поводу и без. Если я еду на машине в ближайшую пивную, то мне не нужно быть пилотом болида Формулы 1 и читать 20 страниц документации, чтобы включать передачи. Это нужно гонщикам и автомеханикам. Рекламирование Git как серебряной пули выглядит как продажа в автосалонах болидов F1 под предлогом "оно быстрее ездит и круче смотрится".

Minoru комментирует...

virens поломался, называет молодой систему, созданную лишь на год позже Git и Mercurial (и на год раньше Bazaar!), а ставить предлагает скачиванием бинарника с официального сайта :(

Ещё у тебя немного едет разметка: вертикальные отступы перед «Начало работы с Fossil» и «Недостатки Fossil» больше, чем перед остальными заголовками. Когда ты наконец перейдёшь на hakyll/jakyll/whatever и начнёшь верстать блог в TeX? :) Ещё есть проблемы с блоками кода: кое-где они у тебя аккурат между абзацами, а кое-где как бы «прилипают» к предыдущему (т.е. нет отступа сверху). Более того, кое-где в блоки с кодом закрался и обычный текст (например, в разделе о добавлении файлов).

Про симметричный push в Git стоило бы объяснить поподробнее, или хотя бы ссылку какую дать — я, как и iv_vl, не знал о такой проблеме, хотя гитом пользуюсь уже года три. Нет, та ссылка на портянку в семнадцать экранов, что ты дал, не подходит :) Позаимствуй URL из комментария iv_vl — там всё кратко и по сути.

Ну, а теперь традиционный хит-парад придирок, правда, вперемешку с мини-комментариями:

> в меру человеческий синтаксис

Я бы не стал называть интерфейс командной строки синтаксисом.

> атомарные коммиты

Атомарные коммиты — это правило работы, а не свойство СКВ. Ты, часом, терминологию не путаешь?

> параноидальная проверка целостности данных перед коммитом

На глаз — проверок столько же, сколько и в Git.

> например в /usr/local/bin и всё

Вот здесь я бы тире воткнул. И пофиксь этот абзац — у тебя предложения на отдельных строках.

> создание репозитория:
> …
> или клонировать его:

> Каждое важное изменение файлов следует отправлять в репозиторий, снабдив осмысленным комментарием:
> …
> и через некоторое время получим:

Заредактировал статью :)

> будет вывалены все файлы

«Будут».

> двойная проверки правильности

«Проверка».

> В Windows файлы будут использовать CRNL окончания. В Unix системах CRNL комбинации, как правило, использовать нежелательно
> …
> все CR/NL окончания строк

«CRNL окончания», «CRNL комбинации» — ну не по-русски это! Хотя бы порядок слов поменяй, а лучше — перепиши весь абзац, а то тем, кто про переводы строк впервые слышит («как, не Enter?!»), может быть непонятно, о чём вообще речь.

Листинги для pull и push выглядят подозрительно — и там, и там огромные числа в поле Sent.

> чтобы получить изменения.

Этот обрывок лучше втиснуть в текст до кода.

> Серебряной пули по-прежнему нет, но с Fossil на это увеличивается надежда.

«На это» убрать, потом переставить слова в конце предложения — станет лучше ;)

Фух! Я fossil использовал для одного из студенческих проектов — хотелось удобного багтрекера. В результате решил, что простой TODO в корне проекта мне таки удобней. В команде, конечно, ценности совсем другие — если бы нам не подходил GitHub, я бы настоятельно пытался обучить народ fossil'у, да.

Minoru комментирует...

virens комментирует...

> Сначала я должен сделать git add изменённый файл, и только потом git commit.

git commit -a или git commit FILENAME, по ситуации.

virens комментирует...

@iv_vl комментирует...
Спасибо за пост!
Мерси. Я долго его готовил, собирал всякие косяки. И теперь всё в одной кастрюле :-)

Натолкнул на изучение несимметричности push/pull в Гите, решение вопроса здесь!
iv_vl, спасибо, конечно, за ссылку. Но у меня есть другая ссылка. Очень она мне нравится: там человек очень обстоятельно объясняет, почему гит плох. Причём плох не в смысле кривой реализации (как, например, bazaar), а именно идейно плох. И я с тем мужиком полностью согласен.

Не холивара ради. Пусть гит будет, никому не мешает. Просто у меня остались привычки из Subversion, и после этого гит выглядит, мягко говоря, экзотично :-)


@Kostya комментирует...
Вы ещё не до конца умеете его готовить правильно!
Использую сравнительно недавно (менее года), так что да, не успел познать дзен :-)

Но уже очень радует. Сообщения об ошибках, конечно, это просто атас. Долгие коммиты. Кривое перемещение\удаление файлов (ну да, database-backed, а что вы ещё хотели? да ещё и mysql). А так очень здорово всё. И один исполнимый файл почти без зависимостей. Мечта.

Проблемы с synk возникают, потому что synk у вас не такой, как у нормальных людей.
А что, локально уже никто не работает? Все в облаках сидят? :-)

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

Кроме того длительность коммитов возникает ещё и из-за хранения версий в дельтах, а не целиковых файлах.
Естественно. Плюс они там ещё наворотили много проверок. И всё равно долго коммиты идут.

Кстати, тикеты можно менять.
Не знал. Спасибо.

Прелесть в том, что по умолчанию оно и так хорошо. Даже очень хорошо.

Поправьте extra на extras, потому как именно так она называется в хелпе.
О, спасибо. Поправил. Хотя он и на extra отзывается :-)

virens комментирует...

@Minoru комментирует...

Только я ответил предыдущим комментаторам и уже собрался с чувством выполненного долга листать слешдот, а тут ты :-)

а ставить предлагает скачиванием бинарника с официального сайта
Why not?! В репах нет.

Ещё у тебя немного едет разметка
А у меня в Фурифоксе оно нормально выглядит.

Когда ты наконец перейдёшь на hakyll/jakyll
Никогда. Минору, ты мой список проектов видел? Ну вот...

Про симметричный push в Git стоило бы объяснить поподробнее
В комментариях дал.

Позаимствуй URL из комментария iv_vl — там всё кратко и по сути.
Минору, мне не нравится стиль гита. И ссылки в этом персонально мне не помогут. Моя логика принимает Subversion, Mercurial и Fossil, и не принимает ничего отличающегося от вышеперечисленного. И мне лично этого хватает.

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

Атомарные коммиты — это правило работы, а не свойство СКВ. Ты, часом, терминологию не путаешь?
Atomic commits - я имел в виду, что коммит либо принимается целиком, либо не принимается вообще (не так в CVS, например). А что не так с термином?

На глаз — проверок столько же, сколько и в Git.
Much more, trust me.

И пофиксь этот абзац — у тебя предложения на отдельных строках.
Так задумано.

Заредактировал статью :)
Пост писался почти четыре месяца. В разных версиях Фурифокса и админках Блоггера.

«Проверка».
Слушай, а как ты всё это видишь, а?

Минору, серьёзно: захочешь стать корректором в журнале - можешь рассчитывать на рекомендательное письмо от меня в самых восторженных тонах. Я не бог весть какая величина, но всё-таки. Просто приведу им пару постов до твоих правок и после ;-)

«CRNL окончания», «CRNL комбинации» — ну не по-русски это
Блин, давай экзымпл хау ит из ин рашн :-)

Листинги для pull и push выглядят подозрительно — и там, и там огромные числа в поле Sent.
Реальные листинги, между прочим. Помнишь мой пост про GTD in LaTeX? Вот это оно.


Этот обрывок лучше втиснуть в текст до кода.
Не люблю заканчивать абзац кодом. Поправил.

«На это» убрать, потом переставить слова в конце предложения — станет лучше
Отмочил свой вариант. Авось прокатит :-)

Я fossil использовал для одного из студенческих проектов — хотелось удобного багтрекера.
Он там не самый удобный, он он есть. И для этого не надо подымать Trac.

git commit -a или git commit FILENAME, по ситуации.
По ситуации хотелось бы удобства и некоторой консистентности: если файл уже добавлен и изменён, нефиг его коммиттить. Он уже в репозитории, просто изменён. Mercurial и Fossil это понимают и комиттит без выкидонов.


И ещё раз спасибо уважаемому товарищу Minoru за правки.

Minoru комментирует...

> Why not?! В репах нет.

Есть, начиная со Squeeze. По крайней мере, так мне говорят на packages.debian.org. Ты там что, до Etch даунгрейднулся? :)

> > Ещё у тебя немного едет разметка
> А у меня в Фурифоксе оно нормально выглядит.

Посмотрел Firefox'ом (до этого из Chromium'а смотрел — я в нём Google Reader читаю), но там та же фигня. Вот скриншот:
http://ompldr.org/vZXg1eA/2012-07-30-142503_2646x1024_scrot.png

> А что не так с термином?

Я не ожидал посреди обители юзер-френдли встретить настолько низкоуровнёвый термин :) Ок, теперь я понимаю, о чём ты.

Просто так вышло, что атомарным коммитом также называют правило, согласно которому коммиты должны содержать лишь одно логическое изменение. А то есть любители что-то там поковырять и закоммитить скопом, не разбираясь, что к чему относится вообще.

> Слушай, а как ты всё это видишь, а?

В детстве мало капостил, наверное, вот и навёрстываю там, где народ не против :)

> Блин, давай экзымпл хау ит из ин рашн :-)

Я бы написал так: «В Windows в качестве признака конца строки используется комбинация CRNL, а в Unix — просто NL. При переносе файлов между разнородными системами могут возникать как просто неудобства (текст с NL в Windows «вытянется» в одну строчку, а заметка с CRNL в Unix будет содержать какой-то «мусор» в конце каждой строки), так и реальные проблемы (в Unix не будут работать скрипты с CRNL)». Кстати, тот же Git умеет менять CRNL на NL и обратно  — было бы неплохо написать о том, как сделать то же самое в fossil (если это возможно, конечно :)

> Отмочил свой вариант. Авось прокатит :-)

Катит, катит :)

> По ситуации хотелось бы удобства и некоторой консистентности

Я уже понял, что у тебя невосприимчивость к Git, так что не пытаюсь сейчас ничего доказать, просто доношу к сведению, так сказать. Наличие в Git вот этой промежуточной штуки, именуемой stage или index, я считаю одной из самых крутых киллер-фич. Почему? Потому что я могу с головой уйти в правки, а спустя некоторое время опомниться и с помощью stage постепенно вычленить все свои изменения в отдельные, логически атомарные коммиты (я сейчас об инструментах вроде git add --patch и git stash --keep-index). Как то же самое сделать в Fossil или Mercurial?

Kostya комментирует...

> А что, локально уже никто не работает? Все в облаках сидят? :-)

Ну зачем так сразу. Просто синхронизация с чем-то доступным по nfs - это как-то странно, потому что "не удалённо". Я, например, копии своих проектов держу на домашнем сервере и, хотя доступ туда есть и по nfs, синхронизируюсь через http и проблем не знаю.
Вообще, у фоссила есть 3 опции сервера: standalone, *inetd бэкенд, cgi скрипт.

> коммиты будут проходить при ошибке синхронизации и сами ошибки будут внятные.
Вот, например, я выдернул провод и сделал коммит (fsl - это алиас для fossil'а):

kostya $ fsl ci -m "api update"
Autosync: https://kostya@192.168.1.1/save2read.fsl
Bytes Cards Artifacts Deltas
Sent: 130 1 0 0
fsl: SSL: cannot connect to host 192.168.1.1:443 (Network is unreachable)
Total network traffic: 0 bytes sent, 0 bytes received
fsl: Autosync failed
continue in spite of sync failure (y/N)? y

New_Version: c0afc6341f331e2060c110e69094a86a77fc6388
Autosync: https://kostya@192.168.1.1/save2read.fsl
Bytes Cards Artifacts Deltas
Sent: 4403 79 0 3
fsl: SSL: cannot connect to host 192.168.1.1:443 (Network is unreachable)
Total network traffic: 0 bytes sent, 0 bytes received
fsl: Autosync failed

Евгений Сосна комментирует...

Несилен в английском. Подскажите, есть вот такая переписка http://comments.gmane.org/gmane.comp.version-control.fossil-scm.user/7389 , результатом ее есть патч в fossil http://www.fossil-scm.org/fossil/fdiff?v1=fc0553c09d46a625d9149b4dd5fcd4954c3d25a2&v2=295da8c0d2f460ab1ca0465960cc00ba2cb2575d , так вот в windows xp команда для получения бинарного файла определенной ревизии
fossil artifact dbbaf53007f45dbea542704cf723d060df2ef1fb > somefile.exe
добавляет символы перевода строк, в результате файл из binary с определенной сигнатурой превращается в мусор.

Если кто знает как в fossil победить данную проблему буду благодарен. В linux все нормально отрабатывает.

p.s.: сейчас делаю обходным маневром
fossil revert -r revid somefile.exe
fossil undo somefile.exe
но хотелось бы однообразия.

Kostya комментирует...

Передавайте имя файла в качестве параметра:

fossil artifact dbbaf53007f45dbea542704cf723d060df2ef1fb somefile.exe

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

iv_vl комментирует...

@Minoru комментирует…
Когда ты наконец перейдёшь на hakyll/jakyll/whatever и начнёшь верстать блог в TeX? :)
Вот, кстати, уже сколько я virens'у прожужжал про Markdown… Ты себе и работу упростишь, поскольку
Markdown is intended to be as easy-to-read and easy-to-write as is feasible.
И HTML никуда от тебя не убежит, да и няшный вывод в LaTeX будет (для того и другого использую движок Kramdown). virens, твои посты — кладезь мудрости, и их так не хватает в формате, удобном для оффлайн чтения. Твой «Один опыт печати блога в книгу» не то, чтобы не подходит… Но результаты вывода огорчают: выпадают символы, см. страницу 27 (стр. 37 сгенерированного PDF). Чтобы подобной ереси не происходило, на сегодня один только путь: писать в облегченной разметке, которая бы одинаково хорошо экспортировалась в популярные форматы документов.

post-factum комментирует...

> Самое худшее в мире программного обеспечения - когда кто-то решает как вам должно быть удобно за вас.

Всё лирическое отступление я, пожалуй, пропущу, но скажу, что ни SVN, ни CVS до git я не использовал, потому вырос на git, мыслю по-git'овски (да, я помню, как переводится слово «git», не нужно напоминать) и в равной степени считаю, что всё остальное — фуфло :).

Magister комментирует...

Интересно, как по скорости fossil покажет себя на больших объемах.
Допустим, всю историю ядра Linux запихнуть в него. Не подавится?

Anton Yakutovich комментирует...

Спасибо за ликбез, Виренс! Не подозревал о существовании all-in-one решений для ведения проектов. Возьму на карандаш.

> Установка Fossil
Есть в universe репозитории Ubuntu. Предыдущая версия, 1.21.

> Когда ты наконец перейдёшь на hakyll/jakyll
Никогда. Минору, ты мой список проектов видел? Ну вот...

На самом деле никуда переходить не надо. Достаточно переключиться на использование языков разметки типа Markdown. Я недавно перешёл и ощутил вселенское счастье — время на подготовку заметок ощутимо сократилось. Оглядываясь назад, не понимаю, как я всё это время, извините, совокуплялся с редактором Blogger'а и HTML.

Теперь исходники постов хранятся на гитхабе. Легко принимать правки. Я уже писал, что лелею идею совсем отказаться от редактора Блоггера.

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

Агитирую за маркдаун. Смотри, Миша, нас уже трое. Minoru и iv_vl говорят о том же.

Kostya комментирует...

> Интересно, как по скорости fossil покажет себя на больших объемах.
Допустим, всю историю ядра Linux запихнуть в него. Не подавится?


Сдаётся мне, что всей историей ядра почти любая система подавится. А ваш гит и подавно.
Вот разве что rational clear case, супер-монстр централизованных скв, прожуёт и ещё попросит.

Есил же брать только trunk, то почему нет...

Minoru комментирует...

Привет!

> На самом деле никуда переходить не надо. Достаточно
переключиться на использование языков разметки типа Markdown.

М, а что, Blogger уже его понимает? Или ты каким-нибудь pandoc генерируешь огрызок HTML (только содержимое body) и копируешь его в редактор?

virens, внемли разуму комментаторов (могу разлогиниться и написать от имени Анонимуса, хехе), перейди на Markdown! Он простой, вот здесь описание всего нехитрого синтаксиса: http://daringfireball.net/projects/markdown/

Anton Yakutovich комментирует...

@Minoru
> М, а что, Blogger уже его понимает?
К всеобщему огорчению, не понимает. Команда Blogger'а о-о-очень медленно выкатывает фичи. Похоже, всех кинули спасать Google+.

Генерирую HTML с помощью python-markdown. Что-то типа:
markdown_py название_поста.md | xclip
И в буфере готовый HTML для публикации. Сейчас занимаюсь поиском инструмента для постинга в блоггер напрямую, без запуска веб-редактора.

Magister комментирует...

> Сдаётся мне, что всей историей ядра почти любая система подавится.
> А ваш гит и подавно.
> Вот разве что rational clear case, супер-монстр
> централизованных скв, прожуёт и ещё попросит.
> Есил же брать только trunk, то почему нет...

Эм... как бы git как раз таки для ядра Linux первоначально и разрабатывался.
Ну и по поводу истории ядра: http://archive.org/details/git-history-of-linux
Можете попробовать залить в fossil :)

Я это к чему говорю. Приходится работать с проектом, в котором объем исходников составляет порядка 700 Мб.
git позволяет работать с относительно приемлемой скоростью, но, как всегда, скорости не бывает мало :)

Евгений Сосна комментирует...

я вчера запустил импорт истории ядра с github в fossil , к сожалению не получилось... Но интрига сохраняется, т.к. у меня причина оказалась в недостаточном свободном месте на разделе home. :)

virens комментирует...

@Minoru комментирует...
>> Why not?! В репах нет.

>Есть, начиная со Squeeze.


А у меня нет, на apt-cache search fossil отзывается тишиной. У тебя там энтерпрайз-подписка на премиум-репозитории? :-)

Я не ожидал посреди обители юзер-френдли встретить настолько низкоуровнёвый термин
Это был тонкий троллинг и камешек в сторону CVS. Но так как CVS уже давно на кладбище...

коммиты должны содержать лишь одно логическое изменение.
Ну, в общем, да, в идеальном мире со сферическими конями оно так и есть. Но автор...

есть любители что-то там поковырять и закоммитить скопом
... вот этим вот непотребством часто увлекается. Ну не откатывать же правки, да? :-)

Я бы написал так: «В Windows в качестве признака конца строки
О, клёво! Тебя там Тургенев покусал, видать :-) Снёс свой вариант, поставил твой. Спасибо.


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


@Kostya комментирует...
синхронизация с чем-то доступным по nfs - это как-то странно, потому что "не удалённо"
У меня всё проще: синхронизация с внешним винчестером. С коллегами общение такое: встречаемся за рюмкой чая, втыкается флешка, обсуждаются изменения, распивается чай\коньяк\виски, синхронизируем репозитории, обсуждаем направление дальнейшей разработки.

Не то, чтобы я сидел в хибаре без интернета - просто так удобнее. Здесь так носют (с) :-)


@Kostya комментирует...
Передавайте имя файла в качестве параметра:

fossil artifact

Круто, а я не знал. Кстати, в моей версии (1.21) такой команды нет. Но да, не самый свежак.


@iv_vl комментирует...
Вот, кстати, уже сколько я virens'у прожужжал про Markdown
То есть вы меня скопом решили авторитетом задавить, да? :-)
Ну да, я большой и мягкий, меня можно....

Покурить этот ваш Markdown, что ли, в самом деле.

И HTML никуда от тебя не убежит, да и няшный вывод в LaTeX
Да мне он как-то особо без нужды, если честно. Бложик тем и хорош, что тут всегда последняя версия постов. Что-то надо - открыл страничку, воткнул запрос в поиск, и всё.

и их так не хватает в формате, удобном для оффлайн чтения
Так это ж не Война и мир, чтобы листать вечерами, а я не Лев Толстой, и даже не Федорчук, чтоб книги писать :-)

Твой «Один опыт печати блога в книгу» не то, чтобы не подходит
Он есть следствие моей лени по освоению Markdown - ты к этому клонишь?

Но результаты вывода огорчают: выпадают символы
Ты просто не видел предыдущие варианты - там был полный абзац. В смысле, ещё хуже.

Чтобы подобной ереси не происходило, на сегодня один только путь: писать в облегченной разметке
Лениво. Админка блоггера под рукой, а тут вон язык учить :-)

Реквестирую туториал по Markdown для танкистов, солдат и беременных женщин :-))) Готов его принять гостевым постом. Ишшо одним. [подмигивая в сторону iv_vl]

virens комментирует...

@post-factum комментирует...
Всё лирическое отступление я, пожалуй, пропущу, но скажу, что ни SVN, ни CVS до git я не использовал, потому вырос на git
Лирическое отступление было написано для одного гитофаната, а тут я его привёл для красного словца.

Моя проблема как раз в том, что я-то вырос на SVN, после которого переполз на Mercurial и теперь вот пристально смотрю в сторону Fossil. Бекграунд другой, отсюда и проблемы. Вернее, нет проблем, просто гит после этого смотрится... очень странно он смотрится.

@Magister комментирует...
Интересно, как по скорости fossil покажет себя на больших объемах. Допустим, всю историю ядра Linux запихнуть в него. Не подавится?
Хм... заинтересовался.

В общем, "вы заказали - мы сыграли". У меня в каталоге /usr/src есть вот чего:

think@dot:/usr/src$ ls -l
total 24
drwxrwxr-x 24 root root 4096 Mar 26 2010 linux-2.6.33.1
drwxr-xr-x 4 root root 4096 May 10 17:23 linux-headers-3.2.0-0.bpo.1-686-pae
drwxr-xr-x 4 root root 4096 May 10 17:23 linux-headers-3.2.0-0.bpo.1-common
drwxr-xr-x 4 root root 4096 Jul 12 13:42 linux-headers-3.4-trunk-686-pae
lrwxrwxrwx 1 root src 31 Jul 12 13:44 linux-headers-3.4-trunk-common -> linux-headers-3.4-trunk-686-pae
lrwxrwxrwx 1 root root 23 May 10 17:23 linux-kbuild-3.2 -> ../lib/linux-kbuild-3.2
drwxr-xr-x 22 root root 4096 Jun 26 17:15 linux-source-3.4
drwxr-xr-x 2 root root 4096 May 10 09:07 tp-smapi-0.40

то есть пара версий исходников ядер Linux. Занимает много:


think@dot:/usr/src$ du -h

1.3G


Теперь сырцы этих ядер вместе с заголовками импортировал в Fossil.

Запрос на добавление всех файлов:

root@dot:/usr/src# time fs add *
real 0m10.007s
user 0m4.488s
sys 0m1.104s


Теперь коммит всего этого дела:

root@dot:/usr/src# time fs ci -m "Committing all those freaking sources of Linux"
New_Version: f3a1b350633447021d3574aa740c650f58364825

real 11m57.191s
user 1m45.467s
sys 0m13.701s

Не повторяйте это дома! Я это делал на своём ноутбуке T420, и операции с диском в это время тормозили очень прилично (MC по каталогам ходил очччень медленно).

После этого репозиторий занял чуть менее 300Мб (для 1.3Гб сырцов - неплохо!):

root@dot:/usr/src# ls -lh | grep foss
-rw-r--r-- 1 root src 289M Aug 1 17:15 mygtd.foss

virens комментирует...

@Anton Yakutovich комментирует...
Спасибо за ликбез, Виренс!
Пожалуйста. Ты же меня вебдванолем просвещаешь, ну и вот... :-)

Есть в universe репозитории Ubuntu.
Откуда у вас такие модные репозитории? У меня что-то не видно.


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

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


Теперь исходники постов хранятся на гитхабе.
А я храню затравки к постам либо в SpringpadIt, либо в Drafts внутри Blogger.

Антон, а вот вопрос: ну пишешь ты в Markdown, а потом ведь всё равно конвретить. Лишнее звено ведь, и софт ещё искать.

И вопрос с раскраской кода цветом - как затащить это туда?

лелею идею совсем отказаться от редактора Блоггера.
Загрузка картинок всё равно через админку. Или ты решил слать почтой готовый пост на блог?

Если кто-то захочет написать гостевой пост, проще простого. Принимаешь пулл-реквест с заметкой и вуаля
А если этот кто-то Гит не переваривает? :-)


Агитирую за маркдаун. Смотри, Миша, нас уже трое. Minoru и iv_vl говорят о том же.
Да не говори - зажали со всех сторон, ведванольщики эти. Как там в песне-то поётся?

Молодёжь нигде проходу не даёт,
Молодёжь везде и всюду нос суёт.
Молодёжь, молодёжь!
Бьёт баклуши, шутит шутки,
Сушит шишки, дует в дудки
И поёт.


В общем это, убедили. Буду благодарен за ссылки.

@Kostya комментирует...
Сдаётся мне, что всей историей ядра почти любая система подавится.
См. выше комментарий - не подавилась, хотя коммит занял почти 12 минут.

А ваш гит и подавно.
Эй там, на барже - полегче. Не злоупотребляйте плюрализЬмом мнений.

rational clear case, супер-монстр
Денег стоит. А тут задаром :-)


@Minoru комментирует...
virens, внемли разуму комментаторов (могу разлогиниться и написать от имени Анонимуса, хехе)
А я ж тебя всё равно узнаю :-)

перейди на Markdown
Минору, сейчас мне другие вещи делать надо. И в бложик по-хорошему я писать не должен: меня тут обсерватория типа приглашает, надо поднатужиться и кое-что для них сделать. И себя не забыть. И статью в журнал послать. И пару постов дописать в бложик, чтоб не забылось. И в комментах потроллить вечерком. И ещё отдохнуть немного, а то я тоже не железный. Это у ноутбука моего 4 ядра, а у меня одно, и то фиговое :-)

вот здесь описание всего нехитрого синтаксиса
О, спасибо. Я уж тут загуглил немного. Вопрос остаётся: а как это потом в Блоггер воткнуть?

@Anton Yakutovich комментирует...
Генерирую HTML с помощью python-markdown
Ага, понятно. А какая-нибудь смотрелка Markdown?

занимаюсь поиском инструмента для постинга в блоггер напрямую, без запуска веб-редактора.
Дык sendmail же, или exim: текст поста шлём на Mail2Blogger (это блоггеровская фича в настройках, чтобы постинг был по email). Только я не знаю, как картинки передавать таким образом.

@Magister комментирует...
Можете попробовать залить в fossil :)
А я уже попробовал выше. Ничего, прожевало. Не очень быстро, но таки да, вполне.


@Евгений Сосна комментирует...
Но интрига сохраняется, т.к. у меня причина оказалась в недостаточном свободном месте на разделе home
У меня места 300Гб на /home, и 8Гб ОЗУ. Все три ядра импортировались в Fossil, 12 минут времени скрипения винчестером.

Да, спасибо комментаторам за пинок в сторону Markdown. Дабы не плодить оффтопик, можно скидывать ссылки с туториалами и идеями в электропочту или гостевой блог (у кого есть доступ). Буду благодарен и обещаю таки его раскурить.

Евгений Сосна комментирует...

У меня больше академический интерес к импорту всей истории ядра, даже только ветки trunk.

Уточнение к fossil в последних релизах добавили поддержку синхронизации по sftp .

Kostya комментирует...

А где, кроме вышеуказанной ссылки (там только до начала 2010), можно взять всю историю ядра?
Поделитесь командочкой, пжалста.

Я на выходных попробую запустить импорт на сервере.
Причем пускать хочу 2-мя путями: прямой автоматический импорт, а так же "вручную" (вычекнуть из гита, зачекнуть в фоссил).

Евгений Сосна комментирует...

вроде на github загружал Linus Torvalds https://github.com/torvalds/linux

Minoru комментирует...

Касательно раскрашивания кода в постах: это смотря чем Markdown в HTML конвертировать. Есть такая тулза, pandoc называется, она что угодно во что угодно превращает — так вот она, к примеру, использует для раскрашивания кода другую тулзу, pygments. Туториал по Markdown в pandoc здесь: http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown (там есть пара расширений, вроде сносок).

Полезность гостевого поста, с моей точки зрения, сомнительна. Я привёл уже две ссылки, по которым можно быстро всему научиться. Серьёзно, virens, оно интуитивное до невозможности. Вот тебе приходилось когда-нибудь в email имитировать полужирный или курсив с помощью *выделения* /слов/? Ну дык это у тебя Markdown и получался :)

Вот с картинками и редактором да, засада. Второе можно решить каким-нибудь :map :w :!pandoc -f markdown -t html -o %<.html %<CR><CR>:w<CR>, а вот первое — не знаю. Может, Якутович чего на эту тему придумал?

Vlsu комментирует...

@virens
Спасибо за пост. Довольно познавательно. Я ничем таким раньше не пользовался (необходимости не было). Если необходимость появится, то стартовой точкой будет именно этот пост.

@Anton Yakutovich
@Minoru
@iv_vl
Есть вопрос по Markdown. Я предпочитаю вручную править HTML-код, и лишь когда времени мало пользоваться визуальным редактором блоггера. Язык HTML разметки я знаю отлично (как и CSS), дизайн своего блога настраивал сам, разыскивая ресурсы в шаблонах блоггера и вордпресса. Почти во всех визуальных редакторах (не только блоггера) и конвертерах на выходе в HTML-коде образуется много мусора. Например, пропуск строки вместо православного <br> выделяется пустыми абзацами <p></p>; вместо курсивного выделения тегом <i></i> используется <span style="font-style:italic;"></span>. Про остальные моменты я вообще молчу. Таких "маразмов" множество, и без слёз на код смотреть трудно (а браузер и читателей такой разметки искренне жалко).
Так вот, к чему это я: про Markdown в интернете довольно много положительных отзывов, но хотелось бы узнать ваше авторитетное мнение по поводу "мусора" в коде. Есть ли он? Если есть, то много ли его? Есть ли необходимость руками править некоторые элементы (особенно интересно по поводу списков)?

Minoru комментирует...

> А у меня нет, на apt-cache search fossil отзывается тишиной. У тебя там энтерпрайз-подписка на премиум-репозитории? :-)

Страннота. На packages.debian.org говорят, что должно быть.

> > есть любители что-то там поковырять и закоммитить скопом
> ... вот этим вот непотребством часто увлекается. Ну не откатывать же правки, да? :-)

Нет, конечно. Нужно перейти на git и использовать index :) Или остаться на Mercurial и пользоваться расширением record. А вот для fossil я такой штуки не нашёл.

Не знаю, может, при твоём workflow оно тебе и не нужно, но я стараюсь всегда делать коммиты атомарными. Хотя бы для того, чтобы git log был похож на changelog и можно было быстро вникнуть в текущее состояние проекта.

> зажали со всех сторон, ведванольщики эти

Кто? Где? Как они сюда попали? virens, Markdown не для web2.0, а скорее вопреки ему делался. Оно простое и интуитивное.

И ещё про импорт истории Linux в разные СКВ хочу сказать. Господа, вы что-то пытаетесь делать без понимания целей. Для программиста от СКВ нужны быстрые коммиты, быстрые checkout'ы, быстрое переключение между ветками и, по возможности, беспроблемный merge. Так что тестировать нужно в соответствии с этими вот требованиями, а не тем, как быстро что-то там куда-то там импортируется.

А ещё у каждой уважающей себя СКВ есть команды import и export, позволяющие взаимодействовать с другими с помощью unified diffs (патчи).

iv_vl комментирует...

Поскольку товарищ Minory продолжил, то я продублирую свой ответ по Markdown (первоначально отосланный virens'у лично), заодно отвечу и Vlsu. Итак,

@virens комментирует…
И вопрос с раскраской кода цветом - как затащить это туда?
Используй Python Markdown (кстати, лучше всего его 2-ю версию, она лежит на GitHub, устанавливается посредством setup.py) с расширением CodeHilite. Для раскраски используется Pygments, примеры раскраски находятся здесь.

И потом, у меня в постах раскаска есть - мышкой клацать в этом случае удобнее, как мне кажется.
А вот этого делать уже не придется, excuse-moi. Видишь, до чего техника дошла.

Да не говори - зажали со всех сторон, ведванольщики эти.
Markdown используется на GitHub, Stack Overflow, дебдванольщики они такие, да.

Ага, понятно. А какая-нибудь смотрелка Markdown?
Генерируешь HTML и открываешь в браузере по Ctrl+O. А что еще? Мне с Jekyll проще - он запускает локальный сервер, могу видеть посты в том же виде, что и в блоге.

@Vlsu комментирует…
пропуск строки вместо православного
выделяется пустыми абзацами <​p​><​/p​>;

Это как раз <​p​><​/p​> «православнее», поскольку выделяет логическую структуру — абзац, а <​br​>, чаще всего, — лишняя сущность. Захотел ты каждый абзац начинать с буквицы, то текст на абзацы разделять и надо, выкидывая все <​br​>.

вместо курсивного выделения тегом <​i​><​/i​>…
В HTML5 большее распространение получают теги <​em​><​/em​> для курсива и <​strong​><​/strong​> для полужирного. Почему — неплохо рассказано здесь.

…используется <​span style="font-style:italic;"​><​/span​>
Трансляция Markdown зависит от движка, скорее всего это будут <​em​> и <​strong​>.

Magister комментирует...

И ещё про импорт истории Linux в разные СКВ хочу сказать. Господа, вы что-то пытаетесь делать без понимания целей. Для программиста от СКВ нужны быстрые коммиты, быстрые checkout'ы, быстрое переключение между ветками и, по возможности, беспроблемный merge. Так что тестировать нужно в соответствии с этими вот требованиями, а не тем, как быстро что-то там куда-то там импортируется.
Я про историю Linux начал вобщем из-за того, что fossil всю историю хранит в одном файле - базе sqlite.
Соответственно, он будет расти и расти - и вот интересно как раз то, замедлятся ли (и если да - насколько) указанные вами операции.
Также как быстро можно будет посмотреть историю коммитов, делать такие вещи как bisect и и.п.

Minoru комментирует...

Упс… Я упустил просьбу Виренса писать про Markdown на почту. Прошу прощения.

Vlsu комментирует...

@iv_vl
Это как раз <​p​><​/p​> «православнее», поскольку выделяет логическую структуру — абзац, а <​br​>, чаще всего, — лишняя сущность
Прошу прощения, неправильно сформулировал свою мысль. Я имел в виду ситуацию, когда при наличии нескольких абзацев (<​p​>) с настроенными на CSS для них отступами снизу/сверху, возникает желание отступ увеличить. Для этого <​br​> как раз и пригодится. А некоторые редакторы вместо

<​p​>первый абзац<​/p​>
<​br​>
<​p​>второй абзац<​/p​>

вытворяют что-то вроде

<​p​>первый абзац<​/p​>
<​p​>&nbsp;<​/p​>
<​p​>второй абзац<​/p​>

От этого пустая строка очень широкая (сказываются CSS отступы до и после), что выглядит некрасиво и без прямого вмешательства в код почти не решаемо...

В HTML5 большее распространение получают теги
Про это я прекрасно знаю. Жаль, что сам HTML5 и CSS3 большое распространение пока не получили. Сейчас пишу эти строки из Firefox 14.0.1 (под Ubuntu 12.04). Тест HTML5 (http://html5test.com/) - 345 (+9 бонусных) из 500; тест CSS3 (http://css3test.com/) - 51%. Прямо говоря, результаты не очень радуют. Больше фаерфокса разве что Хром выжмет, и то не намного...
А сколько людей до сих пор используют более старые версии браузеров?
Так что пока лучше не экспериментировать и использовать старые добрые теги, которые понимают все, даже браузеры телефонов...

Anton Yakutovich комментирует...

@virens
> А картинки загружать как? Без админки всё равно никак.
Сам над этим вопросом бился. Нашёл решение. Картинки загружаю гугловским скриптом googlecl. Написал, как это выглядит в дикой природе.

> И потом, у меня в постах раскаска есть - мышкой клацать в этом случае удобнее, как мне кажется.
И вопрос с раскраской кода цветом - как затащить это туда?

Про pygments и тп уже ответили. Всё можно раскрасить автоматически.

> Антон, а вот вопрос: ну пишешь ты в Markdown, а потом ведь всё равно конвретить.
Это такая мелочь по сравнению с остальным профитом, что даже обсуждения не стоит. Поверь мне :-)

> Загрузка картинок всё равно через админку. Или ты решил слать почтой готовый пост на блог?
Загрузка картинок одной левой через googlecl. Никаких проблем — чистый unixway.
Нет, я не использую почту для публикации постов. У Гугла есть библиотека на питоне для доступа к API их сервисов: python-gdata. На базе этой библиотеки существует куча интересных (и иногда работающих) скриптов. Сделал «рисёрч» битбакета и гитхаба, обнаружил там практически инструмент моей мечты — frogstarb. Скрипт на питоне позволяет публиковать и обновлять уже существующие посты. Мне удалось заставить его работать. Когда доведу до ума, напишу в блоге, что и как. Уже сейчас прикрутил у себя в «Колоде» кнопку «исправить статью», можешь заценить гитхабизацию :-)

> А если этот кто-то Гит не переваривает? :-)
Почтовыми голубями могут отправить патч :-)

> Ага, понятно. А какая-нибудь смотрелка Markdown?
Их есть у нас. ReText.

Анонимный комментирует...

fossil есть в squeeze. в энтерпрайз-редакции - dvd4 или cd29 для i386.

Отправить комментарий

Подписаться на RSS-ленту комментариев к этому посту.