Comments 77
Опечатка в слове репозитария, должно быть репозитория.
Спасибо за статью, Fossil — действительно интересная штука по своей архитектуре, но, если честно, каких-то преимуществ перед другими DVCS (в частности, перед гитом) пока не видно. На первый взгляд, набор операций, фактически, тот же самый, за исключением непривычных названий (странно, что общепринятый Carriage-Return-Line-Feed здесь назвали Carriage-Return-New-Line). Жду вторую часть :)
И кстати, «repository» переводится на русский всё же как «репозитoрий». На хабре была не так давно замечательная статья на эту тему, но я её что-то не могу найти…
И кстати, «repository» переводится на русский всё же как «репозитoрий». На хабре была не так давно замечательная статья на эту тему, но я её что-то не могу найти…
Как раз по архитектуре, кстати, фоссил мало отличается от гита. Просто складывается всё в SQLite, а не в файловую систему, ну и баги-вики есть.
Интерфейс поудобнее, чем в гите, но до меркуриала — как до луны. Настроить под себя сложно, потому как очень мало «ручек», за которые можно покрутить. Ну и слабое сообщество — тоже не преимущество.
Интерфейс поудобнее, чем в гите, но до меркуриала — как до луны. Настроить под себя сложно, потому как очень мало «ручек», за которые можно покрутить. Ну и слабое сообщество — тоже не преимущество.
Извините за возможно глупый вопрос, но в чем конкретно преимущества fossit перед git'ом? Вики и веб-интерфейсом сейчас никого не удивишь.
Если при записи в одну единственную БД происходит сбой, весь репозиторий накрывается? Как-то подход git на файлах надежнее выглядит.
Как поведет себя SQLite с базой размером в гигабайт? Все блобы же в базе, как я понял.
Что такое открыть/закрыть репозиторий? Почему закрывать не рекомендуется, зачем тогда эта функция вообще?
Система имеет встроенный ACL что ли? Зачем пользователи нужны на локальной машине?
Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS?
К сожалению, из статьи я вообще не понял зачем нужен этот Fossil и в чем преимущество, кроме как легкости установки под ОС Windows (а что git или mercurial сложно устанавливаются там?) и легкости копирования репозитория (в git достаточно скопировать директорию .git, если нет возможности сделать git clone)
Как поведет себя SQLite с базой размером в гигабайт? Все блобы же в базе, как я понял.
Что такое открыть/закрыть репозиторий? Почему закрывать не рекомендуется, зачем тогда эта функция вообще?
Система имеет встроенный ACL что ли? Зачем пользователи нужны на локальной машине?
Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS?
К сожалению, из статьи я вообще не понял зачем нужен этот Fossil и в чем преимущество, кроме как легкости установки под ОС Windows (а что git или mercurial сложно устанавливаются там?) и легкости копирования репозитория (в git достаточно скопировать директорию .git, если нет возможности сделать git clone)
Если при записи в одну единственную БД происходит сбой, весь репозиторий накрывается? Как-то подход git на файлах надежнее выглядит.Необходимость резервного копирования никто не отменял.
Как поведет себя SQLite с базой размером в гигабайт?Не знаю, не пробовал. Честно говоря, не представляю себе проекта такого размера, если, конечно, большие бинарные файлы в репозиторий не пихать. Учтите к тому же, что Fossil сжимает рабочие файлы. У меня самый большой рабочий каталог исходников — 6 мегабайт с копейками, а соответствующий Fossil репозиторий — чуть больше полутора мегабайт.
Что такое открыть/закрыть репозиторий? Почему закрывать не рекомендуется, зачем тогда эта функция вообще?В тексте же написано — при открытии создается служебная БД для отслеживания изменений в репозитории. Не рекомендую закрывать — просто чтобы не открывать опять, когда на следующий день возьметесь за работу. Можно ведь и забыть.
Зачем пользователи нужны на локальной машине?На локальной машине пользователи не нужны. Но ведь при создании репозитория Fossil не знает, будете вы его использовать локально или на сервере.
Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS?Ниже все правильно ответили. Добавлю, что в Fossil это работает и на локальном компьютере, для локального репозитория, нет нужды в сторонних сервисах, которые могут отвалиться или изменить свою политку в любой момент.
Как пользователь Fossil, отвечу на некоторые ваши вопросы:
Если при записи в одну единственную БД происходит сбой, весь репозиторий накрывается?В соответствии с документацией Fossil незавершенная транзакция будет отменена при следующем открытии базы. Такой подход мне кажется более надежным, чем дерево файлов. (оригинал: A Fossil repository is an SQLite database, so it highly resistant to damage from a power-loss or system crash — incomplete transactions are simply rolled back after the system reboots.
Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS?— Fossil проектируется как «all in one», основное преимущество fossil перед связкой VCS + WIKI&BugTracker в том, что в fossil для поднятия как локального репозитория, так и сервера для репозиториев необходимо минимальное количество действий, что удобно для домашних и небольших распределенных проектов.
Как поведет себя SQLite с базой размером в гигабайт?Мне сложно представить репозиторий ТАКИХ размеров, но довелось иметь дело с репозиторием размером в 200 мб. Перфоманс упал, но не значительно.
В соответствии с документацией Fossil незавершенная транзакция будет отменена при следующем открытии базы. Такой подход мне кажется более надежным, чем дерево файлов.Совершенно верно. Процитирую комментарий с stackoverflow:
The fact that there's a tried'n'true transactional database behind every operation makes me sleep better at night. Yes, we've been through more than one horrible incident of stale and corrupt Subversion repositories (thankfully, a helpful community helped us fix them.) I can't imagine that happening in Fossil. Even Subversion 1.7.x use Sqlite now for metadata storage. (Try turning off power in the midst of a git commit — it'll leave a corrupt repos!)
Тот факт, что каждая операция обеспечивается реально транзакционной базой данных, позволяет мне спать спокойно. Мы пережили не один ужасный инцидент, связанный с повреждением хранилищ Subversion (к счастью, сообщество помогло нам справиться с ними ). Я не могу себе представить, чтобы такое случилось с Fossil. Даже Subversion 1.7 использует теперь Sqlite для хранения метаданных. ( Попробуйте выключить питание посреди commit в git — ваш репозитарий будет поврежден! )
В соответствии с документацией Fossil незавершенная транзакция будет отменена при следующем открытии базы. Такой подход мне кажется более надежным, чем дерево файлов.
С чего это он более надёжный не понятно. Git при коммите создаёт только новые новые файлы и не меняет старые, так что испортить ничего не может.
Fossil проектируется как «all in one»
Это вроде как противоречит известным принципам проектирования. Опять же не знаю как в Windows, но в ОС с пактными менеджерами установка что fossil, что git это одно и тоже стандартное действие.
Мне сложно представить репозиторий ТАКИХ размеров, но довелось иметь дело с репозиторием размером в 200 мб. Перфоманс упал, но не значительно.
$ du -sh .git
311M .git
311M total
Это ещё маленький размер. Я в git храню вообще всё, от результатов вычислений (могут быть десятки МБ) до картинок, а не только коды программ. Размер репозиториев ядра Linux, QT, xorg и тп тоже как бы не маленький. Зачем сразу себя загонять в рамки немасштабируемой системы, когда можно пользоваться масштабируемой прикладывая те же усилия?
С чего это он более надёжный не понятно. Git при коммите создаёт только новые новые файлы и не меняет старые, так что испортить ничего не может.
предлагаю провести тест и сэмулировать ситуацию с «недописаным» файлом в дереве.
для эмуляции я использовал следующие шаги:
1) склонировал репозиторий git
2) удалил файл с наиболее поздней датой изменения
=>
$git status
fatal: unable to read tree 6b711a2ac75bc3cfe9a37e1d2f263dfef93db584
А под «принципами проектирования» вы видимо имеете ввиду философию Unix? Вы действительно считаете, что она подходит под данный случай?
Опять же не знаю как в Windows, но в ОС с пактными менеджерами установка что fossil, что git это одно и тоже стандартное действие.
Подскажите, какое стандартное действие установит клиент, сервер, wiki, баг трекер и web ui для git? Для fossil это «apt-get install fossil»
> предлагаю провести тест и сэмулировать ситуацию с «недописаным» файлом в дереве
Тест некорректен. При записи коммита сначала записываются блобы, потом tree, потом commit, потом обновляется ветка. Если вы тестируете падение во время записи коммита, откатывайте изменения с конца. Нетрудно видеть, что репозиторий всегда остаётся в консистентном состоянии: ветка обновится только когда коммит будет целиком записан, коммит — только когда будут записаны все его tree, tree — только после блобов, так что как и с транзакцией fossil, потеряем только текущий коммит. Однако, в отличие от fossil, уже записанные части коммита можно будет извлечь, а не потерять навсегда при rollback'е транзакции. Так что git всё-таки надёжнее.
Тест некорректен. При записи коммита сначала записываются блобы, потом tree, потом commit, потом обновляется ветка. Если вы тестируете падение во время записи коммита, откатывайте изменения с конца. Нетрудно видеть, что репозиторий всегда остаётся в консистентном состоянии: ветка обновится только когда коммит будет целиком записан, коммит — только когда будут записаны все его tree, tree — только после блобов, так что как и с транзакцией fossil, потеряем только текущий коммит. Однако, в отличие от fossil, уже записанные части коммита можно будет извлечь, а не потерять навсегда при rollback'е транзакции. Так что git всё-таки надёжнее.
У вас пропала только ссылка на коммит в текущей ветке. Даже сам коммит вы можете извлечь и поставить на него ссылку. Всё. А теперь попробуйте вбить рандомные данные в середину файла SQLite, то же будет ошибка чтения с непредсказуемыми последствиями. С учётом того, что репозиторий это огромный блоб (кто догадался хранить бинарники в базе???) вероятность убить его целиком намного выше, чем испортить всю кучу мелких файлов.
Причём тут unix, любая модульная программа лучше чем немодульная.
Вы не поверите, но кроме баг-трекера и wiki это apt-get install git. Любой другой баг-трекер или целый комбайн типа github ставится ненамного сложнее. А теперь как мне удалить баг-трекер и wiki из fossil, если они мне не нужены?
А под «принципами проектирования» вы видимо имеете ввиду философию Unix? Вы действительно считаете, что она подходит под данный случай?
Причём тут unix, любая модульная программа лучше чем немодульная.
Подскажите, какое стандартное действие установит клиент, сервер, wiki, баг трекер и web ui для git? Для fossil это «apt-get install fossil»
Вы не поверите, но кроме баг-трекера и wiki это apt-get install git. Любой другой баг-трекер или целый комбайн типа github ставится ненамного сложнее. А теперь как мне удалить баг-трекер и wiki из fossil, если они мне не нужены?
Причём тут unix, любая модульная программа лучше чем немодульная.
Вы действительно считаете, что «немодульная» программа — и программа с «all-in-one» функциональностью представленная одним исполняемым файлом это синонимы? Если вас интересует модульность fossil, вы можете ознакомиться с его исходным кодом: www.fossil-scm.org/index.html/tree?ci=trunk
Также можете обратить внимание, что сайты fossil и sqlite — полностью созданы с помощью web ui fossil.
Вы не поверите, но кроме баг-трекера и wiki это apt-get install git. Любой другой баг-трекер или целый комбайн типа github ставится ненамного сложнее. А теперь как мне удалить баг-трекер и wiki из fossil, если они мне не нужены?
На этот вопрос лучше всего ответил автор Fossil:
Note that I wrote fossil because no other DVCS met my needs. On the other hand, my needs are not your needs and so only you can judge whether or not fossil is right for you. But I do encourage you to at least have a look at the documentation and try to understand the problem that fossil is trying to solve before you dismiss it.
Обратите внимание, что я написал fossil, потому что никакая другая DVCS не соответствовала моим нуждам. C другой стороны, мои нужды — это не ваши нужды, так что только вы можете судить, подходил ли вам fossil. Но я советую вам (призываю вас) хотя бы открыть документацию и попробовать понять задачи, которые fossil пытается решить, прежде чем отказываться от него.
Это всё хорошо, но там тут предлагают пользоваться некой системой, которая не обладает ни единым преимуществом перед другими (кроме баг-трекера) и может делать всё тоже самое, что и другие. "no other DVCS met my needs" я вот и пытаюсь добиться какие my needs заполнил fossil, чего нет в других системах? Если это только баг-треккер, то это печально.
С точки зрения DVCS fossil предоставляет все те же возможности, что и остальные, тут у него ничего нового нет…
Основные преимущества fossil — инфраструктурные, именно «all in one»: интегрированость компонентов, общее удобство и комфорт.
У меня, например, нет склонности к администрированию, я не хочу отдельно настраивать службы баг–трекинга, вики, блога и пр. следить за их совместимостью, сопрягать их. Я хочу просто работать над своими проектами, и тут fossil как раз предоставляет мне полный комплект необходимых мне средств.
Основные преимущества fossil — инфраструктурные, именно «all in one»: интегрированость компонентов, общее удобство и комфорт.
У меня, например, нет склонности к администрированию, я не хочу отдельно настраивать службы баг–трекинга, вики, блога и пр. следить за их совместимостью, сопрягать их. Я хочу просто работать над своими проектами, и тут fossil как раз предоставляет мне полный комплект необходимых мне средств.
Не совсем с вами согласен, на самом деле fossil имеет отличия в реализации как DVCS, которые делают его удобнее, чем git (для меня).
www.fossil-scm.org/index.html/doc/tip/www/fossil-v-git.wiki
www.fossil-scm.org/index.html/doc/tip/www/fossil-v-git.wiki
А теперь попробуйте вбить рандомные данные в середину файла SQLite, то же будет ошибка чтения с непредсказуемыми последствиями. С учётом того, что репозиторий это огромный блоб (кто догадался хранить бинарники в базе???) вероятность убить его целиком намного выше, чем испортить всю кучу мелких файлов.
Опять же, никто не ответит на ваш вопрос лучше чем автор fossil:
www.fossil-scm.org/index.html/doc/tip/www/selfcheck.wiki
Мой тест был некорректен. А вы можете предложить корректный сценарий, при котором в середину sqlite файла попадут рандомные данные (за исключением повреждения носителя)?
Попробую ответить всем сразу. Я перешёл на fossil с SVN и bazaar для домашних проектов по следующим причинам:
По другим вопросам:
Резюмируя: fossil полезен тем, что у него «всё включено» и идеально подходит для небольших/домашних нужд.
- Как система контроля версий он предоставляет всё то же самое, что и git, mercurial, bazaar и пр. DVCS.
- Его преимущества (для меня) перед остальными:
- Не требует никакой установки, достаточно просто скачать один файл.
- Репозиторий лежит в одном файле, поэтому можно смело бросать его в DropBox, с git такого например делать нельзя. Также сразу отпадает необходимость как-то дома или где-то ещё поднимать сервер
- Встроенный web-ui с распределённой Wiki — позволил закрыть для меня проблему личного сервера заметок. Это особенно удобно, когда нет интернета, но есть клон репозитория на флешке, после восстановления соединения достаточно выполнить слияние.
По другим вопросам:
- Как поведет себя SQLite с базой размером в гигабайт? — это скорее всего не будет в его области применимости
- Зачем пользователи нужны на локальной машине? — fossil можно запустить в режиме веб–сервера, и пользователи нужны, чтобы разграничить доступ
- Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS? — интегрированость, отсутствие необходимости особо настраивать, сопрягать и прочих администраторских действий
- Что такое открыть/закрыть репозиторий? — связать/отвязать рабочую папку с репозиторием. Почему не автор статьи не рекомендует закрывать я не знаю, так как если я закончил работу, я обычно удаляю рабочие папки, сохраняя их только в репозитории
Резюмируя: fossil полезен тем, что у него «всё включено» и идеально подходит для небольших/домашних нужд.
Репозиторий лежит в одном файле, поэтому можно смело бросать его в DropBox, с git такого например делать нельзя
Не совсем понятно, как Вы «бросаете файлы в Dropbox». У меня десятки git-репозиториев через него синхронизируются между машинами абсолютно без проблем. Не представляю, как у Вас это могло не получиться.
Есть теоретическая вероятность, что если одновременно коммитить в репозиторий, который лежит в dropbox'е, то он будет порушен, так как Dropbox синхронизирует пофайлово и ничего не знает о структуре git.
пример
пример
А, теперь понятно. Да, я не имею привычки находиться одновременно за рабочим и домашним компами, поэтому эта проблема для меня не сильно актуальна. Вот и не подумал о ней.
Хм, а прямо в примере по Вашей ссылке есть противоположный комментарий:
Понятно, что вероятность потому и называется вероятностью, что случается не всегда и не у всех, однако в случае с повреждениями файлов в Dropbox наш герой Fossil не имеет принципиально большого преимущества. Если повредится файл с его репозиторием, мы ведь точно так же не сможем его прочитать, как и сломанный репозиторий git. Поэтому мне это «преимущество fossil» кажется больше похожим на миф, нежели на факт.
Hey,
I've had a github hosted blog sitting on my dropbox for a long time. I use it from various machines and it even has a daily commit job (for those times when my wandering brain forgets to commit changes).
Not seen this wonky behavior yet.
Понятно, что вероятность потому и называется вероятностью, что случается не всегда и не у всех, однако в случае с повреждениями файлов в Dropbox наш герой Fossil не имеет принципиально большого преимущества. Если повредится файл с его репозиторием, мы ведь точно так же не сможем его прочитать, как и сломанный репозиторий git. Поэтому мне это «преимущество fossil» кажется больше похожим на миф, нежели на факт.
Здесь имеется ввиду не физическое повреждение файла, а порча структуры: при конфликтах DropBox переименовывает файлы.
В случае одного файла это легко заметить, а в случае когда были переименованы файлы где-то внутри .git это будет не так легко.
В случае одного файла это легко заметить, а в случае когда были переименованы файлы где-то внутри .git это будет не так легко.
Суть проблемы стала более понятна, но, повторюсь, ни разу от неё не страдал, несмотря на то, что использую git-репозитории в Dropbox давно и активно. Но на заметку возьму…
Пример несколько неудачен, так как там конфликт между GitHub (приложением) и dropbox. У git вполне простая и понятная иерархия файлов, в случае конфликта на уровне dropbox можно разве что «потерять хеш правильного коммита», что тривиально решается используя «резервную» копию, которую дропбокс делает при «мерже» разных версий.
А если конфликт будет на уровне «вот у нас один файл с sqlite, и второй файл, разруливай», то ситуация звучит несколько сложнее.
А если конфликт будет на уровне «вот у нас один файл с sqlite, и второй файл, разруливай», то ситуация звучит несколько сложнее.
А если конфликт будет на уровне «вот у нас один файл с sqlite, и второй файл, разруливай», то ситуация звучит несколько сложнее.
Это же стандартная ситуацию для DVCS: просто выполняешь слияние репозиториев.
Эм… поподробнее, пожалуйста, расскажите, как сливать два SQLIte-файла.
Это не просто два SQLite–файла, это два репозитория:
Допустим есть repo.fossil и repo.2014-08-29.fossil
Выбираем repo.fossil как основной, открываем его:
Сливаем изменения из второго:
Смотрим, что изменилось, копируем Id второго листа:
Сливаем изменения в текущей рабочей папке:
Фиксируем:
Допустим есть repo.fossil и repo.2014-08-29.fossil
Выбираем repo.fossil как основной, открываем его:
fsl open repo.fossil
Сливаем изменения из второго:
fsl pull repo.2014-08-29.fossil --once
Смотрим, что изменилось, копируем Id второго листа:
fsl ui
Сливаем изменения в текущей рабочей папке:
fsl merge --integrate ID
Фиксируем:
fsl ci
Я о том что база данных — это блоб, слияние нельзя (вернее — нетривиально) выполнить вручную. Если fossil умеет разрешать конфликты на уровне двух хранилищ — это хорошо. Если нет, то с дропбоксом у него может возникнуть более существенна проблема чем у git.
Почему не автор статьи не рекомендует закрывать я не знаю, так как если я закончил работу, я обычно удаляю рабочие папки, сохраняя их только в репозитории
Для меня репозиторий, все-таки, вспомогательный инструмент и я никогда не удаляю рабочие файлы. А держу открытым — потому что если закрою и забуду опять открыть перед редактированием своих файлов, то придется при последующем открытии говорить ему, чтобы он их не перезаписывал — и если окажусь недостаточно внимателен ( день плохой окажется ), то…
Резюмируя: fossil полезен тем, что у него «всё включено» и идеально подходит для небольших/домашних нужд.
Небольших — понятие относительное. Сам Fossil, да и тот же SQLite вполне благополучно живут на нем. Это, конечно, не очень большие проекты, но и не маленькие.
Я удаляю файлы из принципа, чтобы не было незавершенных работ, изменения которых не отразились в репозитории (был у меня в истории печальный случай).
Так я поддерживаю свою внутреннюю дисциплину, а заодно такой подход заставляет внимательно относиться к бэкапам.
Так я поддерживаю свою внутреннюю дисциплину, а заодно такой подход заставляет внимательно относиться к бэкапам.
Каждый день в конце работы делаете commit, close и удаляете файлы? Или я не так понял?
Ещё раз уточню: это всё относится к моим домашним проектам.
А так да, после завершения работы, я всё удаляю, так как к ним я вернусь по мере сил и времени. И это может быть через дни, иногда и месяцы.
На работе я этим, конечно, не занимаюсь, но всё равно чувствую дискомфорт, если у меня долго висят незафиксированные изменения.
А так да, после завершения работы, я всё удаляю, так как к ним я вернусь по мере сил и времени. И это может быть через дни, иногда и месяцы.
На работе я этим, конечно, не занимаюсь, но всё равно чувствую дискомфорт, если у меня долго висят незафиксированные изменения.
Опять же не понятно зачем. Можно сделать отдельную ветку для идей и коммитить туда незавершенное, можно делать stash, если не хочется делать коммит прямо сейчас, можно изменить старый коммит через --amend. Любая другая DVCS это позволяет. Что тут даёт fossil с внесением новой сущности открытия/закрытия не понятно.
2. Его преимущества (для меня) перед остальными:Как ловко у вас n пунктов превратились в n+1. ;-)
3. Не требует никакой установки, достаточно просто скачать один файл.
Репозиторий лежит в одном файле, поэтому можно смело бросать его в DropBox, с git такого например делать нельзя.
В гите достаточно скопировать скрытую папку, разве нет? Много раз переносил репозиторий, проблем не помню.
Встроенный web-ui с распределённой Wiki — позволил закрыть для меня проблему личного сервера заметок. Это особенно удобно, когда нет интернета, но есть клон репозитория на флешке, после восстановления соединения достаточно выполнить слияние.
А расскажите, пожалуйста, поподробнее, как вы организовали работу с заметками с мобильного устройства? Сел изучать fossil с прицелом использовать его как раз для распределённых заметок, но изящного/правильного подхода не вижу.
Для wiki нет merge и возможности организовать древовидную структуру страниц не заметно.
Embedded documentation даёт древовидную структуру, но нельзя править из браузера. Непонятно, можно ли ползать по дереву embedded documentation из браузера. Править в текстовом редакторе и коммитить из консоли на смартфоне, мягко говоря, неудобно.
Вопрос, наверное, к Xitsa, пост которого вы процитировали, я сам смартфонами не пользуюсь.
Т.е., слияние в случае, если параллельно ту же страницу редактирует кто-то другой? Но Xitsa писал о личном сервере заметок.
А если списки ( ul, li,… ) руками прописать?
Для wiki нет merge
Т.е., слияние в случае, если параллельно ту же страницу редактирует кто-то другой? Но Xitsa писал о личном сервере заметок.
и возможности организовать древовидную структуру страниц не заметно.
А если списки ( ul, li,… ) руками прописать?
merge может понадобиться если последовательно произвести правки на разных устройствах пока нет сетевой связности.
Если создание/переименование страния требует обновления оглавления отдельной операцией, то такой подход сразу идёт ф топку. Автоматизировать обновление оглавления при всех возможных операциях вряд ли получится.
Вообще концепция уже примерно вырисовывается: беру zim, с десктопов всё правлю им. Он хранит заметки в txt файлах c разметкой очень близкой к markdown. Содержимое файлов fossil показывает с форматированием даже если на них перейти из дерева файлов, древовидная структура в zim организуется директориями на диске, так что ручное создание оглавления не понадобится.
Если создание/переименование страния требует обновления оглавления отдельной операцией, то такой подход сразу идёт ф топку. Автоматизировать обновление оглавления при всех возможных операциях вряд ли получится.
Вообще концепция уже примерно вырисовывается: беру zim, с десктопов всё правлю им. Он хранит заметки в txt файлах c разметкой очень близкой к markdown. Содержимое файлов fossil показывает с форматированием даже если на них перейти из дерева файлов, древовидная структура в zim организуется директориями на диске, так что ручное создание оглавления не понадобится.
Я, в принципе, добавил к zim поддержку fossil.
Посмотрим, примут ли в основную ветку.
Посмотрим, примут ли в основную ветку.
Тоже активно использую fossil для личных нужд потому что нравится. Сложности в коллективных проектах
— трудно убедить коллег, fossil не популярен, его никто не знает и знать не хочет
— мало бесплатных публичных репозитариев, мне всего один известен
— огромная база opensource кода лежит на github.com, bitbucket.org, code.ggogle.com/p/ и доступна для git или hg. А вот я не могу их оттуда clone или fork и интегрировать в проект средствами fossil.
— трудно убедить коллег, fossil не популярен, его никто не знает и знать не хочет
— мало бесплатных публичных репозитариев, мне всего один известен
— огромная база opensource кода лежит на github.com, bitbucket.org, code.ggogle.com/p/ и доступна для git или hg. А вот я не могу их оттуда clone или fork и интегрировать в проект средствами fossil.
— огромная база opensource кода лежит на github.com, bitbucket.org, code.ggogle.com/p/ и доступна для git или hg. А вот я не могу их оттуда clone или fork и интегрировать в проект средствами fossil.попробуйте:
cd git-repo
git fast-export --all | fossil import --git new-repo.fossil
источник: www.fossil-scm.org/index.html/doc/tip/www/inout.wiki
А как у него с поддержкой в разных IDE?
Можно, конечно, и руками всё комитить, и историю изменений смотреть через web UI / в консоли.
Но гораздо удобнее ведь, когда оно всё прямо «на кончиках пальцев».
Вещи вроде маркировки изменённых строк или полноценных рефакторингов (когда не надо сначала переименовывать файл на диске, а потом в Fossil) всё-таки немалого стоят.
Можно, конечно, и руками всё комитить, и историю изменений смотреть через web UI / в консоли.
Но гораздо удобнее ведь, когда оно всё прямо «на кончиках пальцев».
Вещи вроде маркировки изменённых строк или полноценных рефакторингов (когда не надо сначала переименовывать файл на диске, а потом в Fossil) всё-таки немалого стоят.
Блин, ну не знаю, легкость установки, говорите…
Я, например, даже не помню, как именно устанавливал гит на маке (толи с xcode установился, толи через менеджер пакетов).
Ну то есть, на мой взгляд, скорость установки для системы управления версиями это вообще не тот показатель, который должен рассматриваться ))
Да и потом, на нормальных системах команда вроде apt-get install git — это вообще самый быстрый способ установки, который только можно придумать.
В случае же с Fossil: надо найти их официальный сайт, открыть его, найти, где скачать бинарник, выбрать бинарник под нужную ОС, скачать его, найти его в папке «загрузки», придумать, куда его положить, возможно прописать его в переменную путей — ну капец же!
Я, например, даже не помню, как именно устанавливал гит на маке (толи с xcode установился, толи через менеджер пакетов).
Ну то есть, на мой взгляд, скорость установки для системы управления версиями это вообще не тот показатель, который должен рассматриваться ))
Да и потом, на нормальных системах команда вроде apt-get install git — это вообще самый быстрый способ установки, который только можно придумать.
В случае же с Fossil: надо найти их официальный сайт, открыть его, найти, где скачать бинарник, выбрать бинарник под нужную ОС, скачать его, найти его в папке «загрузки», придумать, куда его положить, возможно прописать его в переменную путей — ну капец же!
В репозитории вашего дистрибутива не представлен fossil?
Под скоростью установки, думаю, имелось ввиду скорость развертывания всей необходимой инфраструктуры для ведения проекта распределенной командой — DVCS, WIKI, Bug-tracker, Web-Ui. (и это apt-get install fossil, если дистрибутив позволяет, или скачать файл, если нет)
Под скоростью установки, думаю, имелось ввиду скорость развертывания всей необходимой инфраструктуры для ведения проекта распределенной командой — DVCS, WIKI, Bug-tracker, Web-Ui. (и это apt-get install fossil, если дистрибутив позволяет, или скачать файл, если нет)
В fossil в графическом режиме удобное представление веток разработки в виде «напластований геологических слоев» (отсюда, кстати, и название fossil — «ископаемое»)
Пример истории чек-инов
Отсюда, кстати, и отсутствие аналога rebase — для разработчиков и пользователей fossil это часть методологии разработки, когда история разработки — нечто важное, что нельзя менять.
А вообще, спор «какая система контроля версий лучше» аналогичен спору «лучший текстовый редактор», «лучшая IDE» и т.д. Кто-то использует fossil, кто-то hg и т.д.
Пример истории чек-инов
Отсюда, кстати, и отсутствие аналога rebase — для разработчиков и пользователей fossil это часть методологии разработки, когда история разработки — нечто важное, что нельзя менять.
А вообще, спор «какая система контроля версий лучше» аналогичен спору «лучший текстовый редактор», «лучшая IDE» и т.д. Кто-то использует fossil, кто-то hg и т.д.
Хранение в одном файле базы данных выглядит удобным для личных целей. Хочу поднять систему контроля версий, для контроля своей работы с различными документами. Насколько fossil будет удобен? Исходя, из определенных сооьражений, файл базы будет лежать в папке Dropbox'а, можно ли будет вполне спокойно продолжить работать с репозиторием на другой системе (текущий ПК но с переустановленной ОС, или же совсем иная машина)?
Fossil будет очень удобен, если документы текстовые, и просто удобен, если бинарные.
С работой на разных системах проблем не будет, fossil к системе никак не привязывается и состоит из единственного исполняемого файла.
С работой на разных системах проблем не будет, fossil к системе никак не привязывается и состоит из единственного исполняемого файла.
А как у него с отслеживанием переименований файл? Столкнулся с тем, что `git log -p` показывает только до момента переименования, причем так, как будто это новый файл. Зная прошлое имя, можно посмотреть и его, но закончится она тоже так, как если файл был удалён. А здесь?
Столкнулся с тем, что git log -p показывает только до момента переименования, причем так, как будто это новый файлЕсть опция --follow.
UFO just landed and posted this here
Да, зато не требует дополнительных ручных действий.
UFO just landed and posted this here
Именно за счёт hg и является. Его можно забыть, следовательно он будет забыт. Это не касаясь других способов получить тот же файл в новом месте при необходимости сохранить историю.
и каким образом дописывание --follow и прочих ключей «угадывай сильнее» не является «дополнительным ручным действием»?
Таким что нужно намного реже и при необходимости прописывается в алиасы. И дело тут даже не в этом — с забытым $VCS cp/mv ничего уже не сделаешь, история потеряна. А с --follow её можно получить всегда.
С --follow её легко можно не получить вообще никогда. LabVIEW, к примеру, хранит исходный код в бинарных файлах, к тому же сжатых и по‐умолчанию содержащих результаты компиляции (хотя те, кто всерьёз использует VCS быстро учится настраивать его так, чтобы не хранил) и кучу других вещей, которые в других языках отсутствуют, не хранятся вместе с исходным кодом или вообще относятся исключительно к IDE (при том из всего разнообразия можно настройкой исключить только результаты компиляции). При этом один файл — одна функция, так что переименования происходят куда как чаще. Как вы думаете, какая максимальная разница между переименованным и исходным файлом? Мне как‐то доводилось видеть 0% по мнению mercurial. Схожесть в 50% после переименования и ещё какого‐то связанного с этим изменения (обычно — такого, без которого обойтись нельзя) уже можно считать хорошей.
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.
Системы контроля версий: Fossil, часть I