Колебания между мерзавцем и ископаемым

Новичок в Fossil (или любой другой системе контроля версий) здесь. Раньше пользовался фирменным, но сам никогда не устанавливал.

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

Я выбрал Fossil в первую очередь потому, что, похоже, лучше всего подходит распределенная версия, она кажется легкой и имеет встроенный багтрекер. Но Git, похоже, является излюбленным SCM для многих. Стоит ли добавлять сложность в пользу Git + someBugTracker перед Fossil? Есть ли лучшие альтернативы? Придется начинать с 0 на всех.


person Samudra    schedule 02.04.2012    source источник


Ответы (1)


Просто мысли, неорганизованные.

Если ваши друзья уже привыкли к gitting, Git - это хороший и надежный распределенный SCM с отличными услугами хостинга, такими как Github или Gitorious.

Хотя концепции Git непросто понять. Fossil имеет аналогичные концепции, но, вероятно, с него легче начать (без промежуточной области, без концепции индекса, возврат изменений с момента последней фиксации с revert, а не reset или checkout и т. Д.). Здесь нет множества подкоманд с множеством опций, помощь краткая и понятная. Если вы боитесь заблудиться, выбирайте ископаемое. Конечно, это также означает, что с fossil вы не можете делать столько же вещей, как с git (например, без перебазирования, по крайней мере, на данный момент).

Для fossil существует несколько доступных онлайн-сервисов хостинга. Настроить сервер для запуска Fossil так же просто, как с Git.

Кроме того, в Fossil история проекта хранится в одном файле, поэтому мне очень легко сделать резервную копию всех проектов: поместить все репозитории в одну папку и выполнить одну задачу rsync. Однако это делает инкрементное резервное копирование совершенно бесполезным.

В то время как с git работа над двумя ветвями в одних и тех же проектах в разных папках означала бы наличие двух копий всей истории проекта и ветвей в двух разных .git/objects каталогах, которые могут быть избыточными и огромными, с Fossil рабочая схема по умолчанию должна иметь одну единый репозиторий и один или несколько подключенных к нему рабочих каталогов. Возможно, если важно использование диска, это будет иметь значение.

Предупреждение, трекер ошибок Fossil (тикетная система на жаргоне) и вики довольно примитивны (хотя и работают хорошо).

person Benoit    schedule 02.04.2012
comment
Клоны Git в том же разделе по умолчанию создают жесткие ссылки. Итак, единственное место, которое вам нужно, - это рабочее дерево. - person knittl; 05.04.2012
comment
@Benoit, обратите внимание, что rsync-ing Fossil repos - это несколько наивный подход, поскольку он не требует никаких операций записи в этот файл базы данных во время его резервного копирования. Единственный надежный подход к оперативному резервному копированию - это использование sqlite3 dump ... и последующее резервное копирование файлов дампа. И резервное копирование Git на самом деле не так уж и сложно: вам просто нужно использовать сам Git для выполнения этой задачи. Более того, если нужно высокопрофессиональное решение, gitolite v3 реализует репликацию master / slave на пушах. - person kostix; 01.06.2012
comment
@kostix: людям нравится делать побитовые резервные копии по нескольким причинам. Хотя я не вижу никаких законных причин для побитового резервного копирования репозитория ископаемых и не делать дамп sqlite3, некоторые люди не захотят этого делать. Кроме того, ископаемое имеет репликацию, но не может реплицировать некоторые данные (как правило, данные, которые fossil scrub удаляет). Если резервное копирование этих данных не требуется, для резервного копирования достаточно просто воспользоваться репликацией. - person Benoit; 01.06.2012
comment
Вы можете использовать git bundle для создания резервных копий. См. Этот вопрос (и ответ): stackoverflow.com/a/11163038/1047741 - person shytikov; 11.07.2012
comment
У меня не было проблем с хранением денег между кассами. Какой вариант использования для нескольких рабочих каталогов? Для меня это больше похоже на хлопот ... - person bug; 24.05.2013
comment
@Benoit: См. rdiff-backup для решения проблемы инкрементного резервного копирования. - person Warren Young; 13.09.2013
comment
@bug: два разработчика, работающие на одной машине (например, на сервере сборки), каждый из которых хочет независимой проверки в своем домашнем каталоге. Проверки переходят в repo.fossil файл, из которого они выполнили проверку. Сравните Git, где им нужно отправлять изменения друг другу, даже если они находятся в одном ящике. - person Warren Young; 13.09.2013
comment
@WarrenYoung Двум разработчикам не обязательно взаимодействовать друг с другом: они могут выполнить отправку в третье основное репо на диске, что обеспечивает централизованный рабочий процесс. Их все равно нужно будет периодически подталкивать и тянуть. Фактически, это также происходит в Fossil, но неявно выполняется при каждой фиксации (в стиле SVN). - person Dan Passaro; 24.09.2014