Но вот сравнительно недавно появившийся Fossil уже несколько возмужал и окреп, и для некоторых не особо больших и важных проектов, кажется, уже годен для использования.
Сейчас мы этим Fossil и займёмся.
Почему Fossil?
Потому, что он имеет несколько killer-features, которых нет у конкурентов:
- все данные хранятся в одном файле, который представляет собой SQLite базу данных, так что файлы не повредятся, если кто-то перенесёт данные на флешке с FAT;
- написан на канонiчном C и представляет собой один-единственный
экзешникисполнимый файл; - wiki, ticket system и графический интерфейс в одном флаконе (здесь привет всем сразу);
- нормальный, человеческий симметричный push и pull (авторам git на этом месте предлагается удавиться);
- имеет адекватную документацию и в меру человеческий интерфейс;
- атомарные коммиты и параноидальная проверка целостности данных перед коммитом.
Установить 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Вообще, отвлекаясь от темы: сообщения об ошибках Fossil это цирк с конями. Иногда кажется, что несколько марсиан из команды инопланетных захватчиков Git затесалось-таки в разработчики Fossil.
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 так не даёт затереть файлы, которые уже есть в другой директории. То есть если мы перемещаем файлы в другую директорию, а они там уже есть, нам выведут вот такое сообщение. Вариантом решения проблемы является предварительное затирание:
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Всё, теперь удалённый репозиторий имеет те же изменения, что и у вас. На том конце следует сделать update и можно продолжать работать.
Bytes Cards Artifacts Deltas
Sent: 19013 13 2 4
Received: 32 1 0 0
Total network traffic: 7346 bytes sent, 244 bytes received
Но не всё так сказочно, и бывает, что мы пытаемся сделать push в репозиторий, в который у нас нет прав это делать. То есть права доступа там, скажем, только на чтение, и попытка пнуть (push) туда изменения:
fossil push /mnt/flash/exthdd/zips/mygtd_fossil/mygtdЭто вот так логично у fossil выглядит сообщение о том, что отправка изменений не удалась из-за отсутствия полномочий:
будет неудачной:
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.
>
beast@notebeast:/mnt/flash/exthdd/zips/mygtd_fossil$ ls -lНе очень понятно, зачем Fossil закатывает такую истерику. Достаточно дать прав командой
итого 2136
-rw-r--r-- 1 1001 users 2183168 2012-02-13 17:49 mygtd
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~Всё сплошь бекапы и лишние файлы, как бы их удалить все разом? На этот счёт у Fossil есть замечательная команда
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 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 можно упомянуть:
- Очень медленная синхронизация репозиториев и коммитов.
- Слишком много мер предосторожности, и, как следствие, очень долгие коммиты.
- Дурные на всю голову сообщения об ошибках.
- Довольно топорная работа с ветками. Если вы создали Leaf и там что-то удалили, закрытие Leaf выйдет вам боком.
Дополнительная информация и ссылки
Fossil Version Control A Users Guide
www.fossil-scm.org/schimpf-book/doc/tip/fossilbook.pdf
File Format: PDF/Adobe Acrobat - Quick View
> То есть когда в коде проекта появляются ошибки, обычно пользуются сторонними сервисами (Track или системой контроля ошибок на bitbucket). В случае с Track это ещё одна программа, которую нужно устанавливать и конфигурировать.
ОтветитьУдалитьНаверное, таки не Track, а Trac.
Спасибо за статью. Интересно было почитать, но git я на него не променяю :).
Спасибо за пост! Натолкнул на изучение несимметричности push/pull в Гите, решение вопроса здесь!
ОтветитьУдалитьСпасибо. Круто
ОтветитьУдалитьВы ещё не до конца умеете его готовить правильно!
ОтветитьУдалитьПроблемы с synk возникают, потому что synk у вас не такой, как у нормальных людей. :P
Обычно синхронизируются с _удалённым_ репозитарием, куда нет доступа по nfs. Т.е. если удалённая репа будет по адресу http, то и коммиты будут проходить при ошибке синхронизации и сами ошибки будут внятные.
Хотя конечно это минус, что с локальными такая фигня (я это никогда не использовал и не знал).
Кроме того длительность коммитов возникает ещё и из-за хранения версий в дельтах, а не целиковых файлах. И потом у меня они всегда проходили максимум за 2-3 секунды (это большие изменения, мелкие около 1й) на проекте с 7-ю метрами чистых исходников.
Кстати, тикеты можно менять. Т.е. можно добавлять/удалять поля, правда для этого придётся немного разобраться, поскольку это делается не мышковозюкательно, а путём задания правильных шаблонов.
PS
Поправьте extra на extras, потому как именно так она называется в хелпе.
@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 под предлогом "оно быстрее ездит и круче смотрится".
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'у, да.
virens комментирует...
ОтветитьУдалить> Сначала я должен сделать git add изменённый файл, и только потом git commit.
git commit -a или git commit FILENAME, по ситуации.
@iv_vl комментирует...
ОтветитьУдалитьСпасибо за пост!
Мерси. Я долго его готовил, собирал всякие косяки. И теперь всё в одной кастрюле :-)
Натолкнул на изучение несимметричности push/pull в Гите, решение вопроса здесь!
iv_vl, спасибо, конечно, за ссылку. Но у меня есть другая ссылка. Очень она мне нравится: там человек очень обстоятельно объясняет, почему гит плох. Причём плох не в смысле кривой реализации (как, например, bazaar), а именно идейно плох. И я с тем мужиком полностью согласен.
Не холивара ради. Пусть гит будет, никому не мешает. Просто у меня остались привычки из Subversion, и после этого гит выглядит, мягко говоря, экзотично :-)
@Kostya комментирует...
Вы ещё не до конца умеете его готовить правильно!
Использую сравнительно недавно (менее года), так что да, не успел познать дзен :-)
Но уже очень радует. Сообщения об ошибках, конечно, это просто атас. Долгие коммиты. Кривое перемещение\удаление файлов (ну да, database-backed, а что вы ещё хотели? да ещё и mysql). А так очень здорово всё. И один исполнимый файл почти без зависимостей. Мечта.
Проблемы с synk возникают, потому что synk у вас не такой, как у нормальных людей.
А что, локально уже никто не работает? Все в облаках сидят? :-)
коммиты будут проходить при ошибке синхронизации и сами ошибки будут внятные.
Сообщения об ошибках у Fossil, скажем так, не самые понятные. Mercurial в этом плане лучше, но его питонья природа меня огорчает: на разных ноутбуках у меня - разный дебиан, и это порождает иногда весёлые приключения с коммитами.
Кроме того длительность коммитов возникает ещё и из-за хранения версий в дельтах, а не целиковых файлах.
Естественно. Плюс они там ещё наворотили много проверок. И всё равно долго коммиты идут.
Кстати, тикеты можно менять.
Не знал. Спасибо.
Прелесть в том, что по умолчанию оно и так хорошо. Даже очень хорошо.
Поправьте extra на extras, потому как именно так она называется в хелпе.
О, спасибо. Поправил. Хотя он и на extra отзывается :-)
@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 за правки.
> 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?
> А что, локально уже никто не работает? Все в облаках сидят? :-)
ОтветитьУдалитьНу зачем так сразу. Просто синхронизация с чем-то доступным по 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
но хотелось бы однообразия.
Передавайте имя файла в качестве параметра:
ОтветитьУдалитьfossil artifact dbbaf53007f45dbea542704cf723d060df2ef1fb somefile.exe
Конвертация символов происходит только при выводе в стандартный поток вывода.
@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). Чтобы подобной ереси не происходило, на сегодня один только путь: писать в облегченной разметке, которая бы одинаково хорошо экспортировалась в популярные форматы документов.
> Самое худшее в мире программного обеспечения - когда кто-то решает как вам должно быть удобно за вас.
ОтветитьУдалитьВсё лирическое отступление я, пожалуй, пропущу, но скажу, что ни SVN, ни CVS до git я не использовал, потому вырос на git, мыслю по-git'овски (да, я помню, как переводится слово «git», не нужно напоминать) и в равной степени считаю, что всё остальное — фуфло :).
Интересно, как по скорости fossil покажет себя на больших объемах.
ОтветитьУдалитьДопустим, всю историю ядра Linux запихнуть в него. Не подавится?
Спасибо за ликбез, Виренс! Не подозревал о существовании all-in-one решений для ведения проектов. Возьму на карандаш.
ОтветитьУдалить> Установка Fossil
Есть в universe репозитории Ubuntu. Предыдущая версия, 1.21.
> Когда ты наконец перейдёшь на hakyll/jakyll
Никогда. Минору, ты мой список проектов видел? Ну вот...
На самом деле никуда переходить не надо. Достаточно переключиться на использование языков разметки типа Markdown. Я недавно перешёл и ощутил вселенское счастье — время на подготовку заметок ощутимо сократилось. Оглядываясь назад, не понимаю, как я всё это время, извините, совокуплялся с редактором Blogger'а и HTML.
Теперь исходники постов хранятся на гитхабе. Легко принимать правки. Я уже писал, что лелею идею совсем отказаться от редактора Блоггера.
Если кто-то захочет написать гостевой пост, проще простого. Принимаешь пулл-реквест с заметкой и вуаля. В общем, не жизнь, а праздник.
Агитирую за маркдаун. Смотри, Миша, нас уже трое. Minoru и iv_vl говорят о том же.
> Интересно, как по скорости fossil покажет себя на больших объемах.
ОтветитьУдалитьДопустим, всю историю ядра Linux запихнуть в него. Не подавится?
Сдаётся мне, что всей историей ядра почти любая система подавится. А ваш гит и подавно.
Вот разве что rational clear case, супер-монстр централизованных скв, прожуёт и ещё попросит.
Есил же брать только trunk, то почему нет...
Привет!
ОтветитьУдалить> На самом деле никуда переходить не надо. Достаточно
переключиться на использование языков разметки типа Markdown.
М, а что, Blogger уже его понимает? Или ты каким-нибудь pandoc генерируешь огрызок HTML (только содержимое body) и копируешь его в редактор?
virens, внемли разуму комментаторов (могу разлогиниться и написать от имени Анонимуса, хехе), перейди на Markdown! Он простой, вот здесь описание всего нехитрого синтаксиса: http://daringfireball.net/projects/markdown/
@Minoru
ОтветитьУдалить> М, а что, Blogger уже его понимает?
К всеобщему огорчению, не понимает. Команда Blogger'а о-о-очень медленно выкатывает фичи. Похоже, всех кинули спасать Google+.
Генерирую HTML с помощью python-markdown. Что-то типа:
markdown_py название_поста.md | xclip
И в буфере готовый HTML для публикации. Сейчас занимаюсь поиском инструмента для постинга в блоггер напрямую, без запуска веб-редактора.
> Сдаётся мне, что всей историей ядра почти любая система подавится.
ОтветитьУдалить> А ваш гит и подавно.
> Вот разве что rational clear case, супер-монстр
> централизованных скв, прожуёт и ещё попросит.
> Есил же брать только trunk, то почему нет...
Эм... как бы git как раз таки для ядра Linux первоначально и разрабатывался.
Ну и по поводу истории ядра: http://archive.org/details/git-history-of-linux
Можете попробовать залить в fossil :)
Я это к чему говорю. Приходится работать с проектом, в котором объем исходников составляет порядка 700 Мб.
git позволяет работать с относительно приемлемой скоростью, но, как всегда, скорости не бывает мало :)
я вчера запустил импорт истории ядра с github в fossil , к сожалению не получилось... Но интрига сохраняется, т.к. у меня причина оказалась в недостаточном свободном месте на разделе home. :)
ОтветитьУдалить@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]
@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
@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 .
А где, кроме вышеуказанной ссылки (там только до начала 2010), можно взять всю историю ядра?
ОтветитьУдалитьПоделитесь командочкой, пжалста.
Я на выходных попробую запустить импорт на сервере.
Причем пускать хочу 2-мя путями: прямой автоматический импорт, а так же "вручную" (вычекнуть из гита, зачекнуть в фоссил).
вроде на github загружал Linus Torvalds https://github.com/torvalds/linux
ОтветитьУдалитьКасательно раскрашивания кода в постах: это смотря чем 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>, а вот первое — не знаю. Может, Якутович чего на эту тему придумал?
@virens
ОтветитьУдалитьСпасибо за пост. Довольно познавательно. Я ничем таким раньше не пользовался (необходимости не было). Если необходимость появится, то стартовой точкой будет именно этот пост.
@Anton Yakutovich
@Minoru
@iv_vl
Есть вопрос по Markdown. Я предпочитаю вручную править HTML-код, и лишь когда времени мало пользоваться визуальным редактором блоггера. Язык HTML разметки я знаю отлично (как и CSS), дизайн своего блога настраивал сам, разыскивая ресурсы в шаблонах блоггера и вордпресса. Почти во всех визуальных редакторах (не только блоггера) и конвертерах на выходе в HTML-коде образуется много мусора. Например, пропуск строки вместо православного <br> выделяется пустыми абзацами <p></p>; вместо курсивного выделения тегом <i></i> используется <span style="font-style:italic;"></span>. Про остальные моменты я вообще молчу. Таких "маразмов" множество, и без слёз на код смотреть трудно (а браузер и читателей такой разметки искренне жалко).
Так вот, к чему это я: про Markdown в интернете довольно много положительных отзывов, но хотелось бы узнать ваше авторитетное мнение по поводу "мусора" в коде. Есть ли он? Если есть, то много ли его? Есть ли необходимость руками править некоторые элементы (особенно интересно по поводу списков)?
> А у меня нет, на 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 (патчи).
Поскольку товарищ 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>.
И ещё про импорт истории Linux в разные СКВ хочу сказать. Господа, вы что-то пытаетесь делать без понимания целей. Для программиста от СКВ нужны быстрые коммиты, быстрые checkout'ы, быстрое переключение между ветками и, по возможности, беспроблемный merge. Так что тестировать нужно в соответствии с этими вот требованиями, а не тем, как быстро что-то там куда-то там импортируется.
ОтветитьУдалитьЯ про историю Linux начал вобщем из-за того, что fossil всю историю хранит в одном файле - базе sqlite.
Соответственно, он будет расти и расти - и вот интересно как раз то, замедлятся ли (и если да - насколько) указанные вами операции.
Также как быстро можно будет посмотреть историю коммитов, делать такие вещи как bisect и и.п.
Упс… Я упустил просьбу Виренса писать про Markdown на почту. Прошу прощения.
ОтветитьУдалить@iv_vl
ОтветитьУдалитьЭто как раз <p></p> «православнее», поскольку выделяет логическую структуру — абзац, а <br>, чаще всего, — лишняя сущность
Прошу прощения, неправильно сформулировал свою мысль. Я имел в виду ситуацию, когда при наличии нескольких абзацев (<p>) с настроенными на CSS для них отступами снизу/сверху, возникает желание отступ увеличить. Для этого <br> как раз и пригодится. А некоторые редакторы вместо
<p>первый абзац</p>
<br>
<p>второй абзац</p>
вытворяют что-то вроде
<p>первый абзац</p>
<p> </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%. Прямо говоря, результаты не очень радуют. Больше фаерфокса разве что Хром выжмет, и то не намного...
А сколько людей до сих пор используют более старые версии браузеров?
Так что пока лучше не экспериментировать и использовать старые добрые теги, которые понимают все, даже браузеры телефонов...
@virens
ОтветитьУдалить> А картинки загружать как? Без админки всё равно никак.
Сам над этим вопросом бился. Нашёл решение. Картинки загружаю гугловским скриптом googlecl. Написал, как это выглядит в дикой природе.
> И потом, у меня в постах раскаска есть - мышкой клацать в этом случае удобнее, как мне кажется.
И вопрос с раскраской кода цветом - как затащить это туда?
Про pygments и тп уже ответили. Всё можно раскрасить автоматически.
> Антон, а вот вопрос: ну пишешь ты в Markdown, а потом ведь всё равно конвретить.
Это такая мелочь по сравнению с остальным профитом, что даже обсуждения не стоит. Поверь мне :-)
> Загрузка картинок всё равно через админку. Или ты решил слать почтой готовый пост на блог?
Загрузка картинок одной левой через googlecl. Никаких проблем — чистый unixway.
Нет, я не использую почту для публикации постов. У Гугла есть библиотека на питоне для доступа к API их сервисов: python-gdata. На базе этой библиотеки существует куча интересных (и иногда работающих) скриптов. Сделал «рисёрч» битбакета и гитхаба, обнаружил там практически инструмент моей мечты — frogstarb. Скрипт на питоне позволяет публиковать и обновлять уже существующие посты. Мне удалось заставить его работать. Когда доведу до ума, напишу в блоге, что и как. Уже сейчас прикрутил у себя в «Колоде» кнопку «исправить статью», можешь заценить гитхабизацию :-)
> А если этот кто-то Гит не переваривает? :-)
Почтовыми голубями могут отправить патч :-)
> Ага, понятно. А какая-нибудь смотрелка Markdown?
Их есть у нас. ReText.
fossil есть в squeeze. в энтерпрайз-редакции - dvd4 или cd29 для i386.
ОтветитьУдалить