fossil: добавить файлы в существующее репо, мне нужно сначала открыть?

Я хочу управлять версиями каталога, назовем его «проектом» и хранить файлы окаменелостей в другом каталоге под названием «окаменелости». Я успешно создал репозиторий "project.fsl", добавил файлы проекта, зафиксировал и закрыл. Моя проблема в том, чтобы понять, как сделать следующий шаг.

Вот что я делаю, следуя fossilbook предложениям.

$ cd project
$ fossil new ../fossils/project.fsl
$ fossil open ../fossils/project.fsl
$ fossil add .
$ fossil ci -m "first commit"
$ fossil close project.fsl

Теперь я работал над своим проектом, отредактировал некоторые файлы, удалил некоторые файлы, создал некоторые файлы, переименовал некоторые файлы. Я хочу добавить текущее состояние проекта в репозиторий. Как мне это сделать?

Основываясь на том, что я прочитал в документе, у меня сложилось впечатление, что мне нужно сначала открыть репозиторий, затем добавить файлы, а затем выполнить фиксацию. Если я не открою репозиторий, я получаю сообщение Not within an open checkout.. Но если я open ископаемый захочет перезаписать мой каталог более старыми файлами. (И если я открываюсь из каталога fossils, я получаю "распакованную" версию моего проекта, скопированную в каталог fossils, а не то, что мне нужно)

$ cd project
$ fossil open ../fossils/project.fsl

Здесь ископаемый хочет перезаписать мой проект более старой версией. Я говорю нет на каждое предложение. Я подозреваю, что open был неправильным подходом, но если нет, то что?

Я хочу добавить свои изменения в репозиторий, поэтому теперь, когда project.fsl равен open, я пробую следующее:

$ fossil add .
 ADDED  Slides/tmp.tex

$ fossil commit -m "no idea what I'm doing, this will not end well"
 would fork.  "update" first or use --allow-fork.

$ fossil close
 there are unsaved changes in the current checkout

На этом этапе я удаляю все скрытые файлы с именем .fslckout .fossil и пытаюсь снова, с такими же неутешительными результатами.

Честно говоря, меня интересует только fossil ведение истории моего проекта. У меня нет соавторов, и я не планирую делать fossil diff или fossil ui или что-то в этом роде до того времени, которое, я надеюсь, никогда не произойдет, когда мне нужно будет копаться в истории моего проекта.

Изменить. Я новичок. Я не уверен, что понимаю значение checkout, manifest, leaf и т. Д., Поэтому мне очень трудно извлечь что-либо из руководства, несмотря на бесчисленные часы, потраченные на попытки. Я не очень понимаю эту страницу на fossil open: http://fossil-scm.org/fossil/help/open


version-control fossil
person PatrickT    schedule 26.02.2014    source источник
comment
Мне известны следующие ссылки по теме: stackoverflow.com/questions/1353382/, stackoverflow.com/questions/14908687/, stackoverflow.com/questions/11051999/, fossil-scm.org/schimpf-book/home, ископаемое -scm.org/fossil/help/open   -  person PatrickT    schedule 26.02.2014
comment
Я бы определенно запустил fossil ui хотя бы один раз, чтобы посмотреть на график. Я визуально ориентирован и знаю, что просмотр списка коммитов на временной шкале мне очень помог, чтобы понять, о чем идет речь.   -  person Martijn    schedule 27.02.2014
comment
@Martijn, теперь, когда у меня работают основные fossil команды, я установил fossil ui с timeline в качестве начального макета, и это действительно очень приятно. Спасибо, что указал на это, Мартейн.   -  person PatrickT    schedule 04.03.2014

Ответы (2)


arrow_upward
4
arrow_downward

fossil open - это правильно. В вашем случае это fossil close, в котором не было необходимости.

На этом этапе вы должны сделать fossil open ../fossils/project.fsl --keep, чтобы открыть репо, сохранив все изменения.

Команда open помечает текущий каталог как рабочий каталог (в терминах Fossil - checkout). Я рекомендую вам не закрывать его, пока вам не понадобится переместить репо или сам рабочий каталог. Лично это происходит только тогда, когда я перехожу на другой компьютер.

Чтобы окаменелость идентифицировала все изменения, просто выполните fossil addremove; Затем fossil добавит все новые файлы и удалит все удаленные файлы, чтобы репозиторий еще раз совпадал с рабочим каталогом. Конечно, после этого вам все равно придется зафиксировать изменения.

Обратите внимание, что addremove не автоматически распознает переименования файлов! Если вы переименовали файлы, вы должны сообщить об этом Fossil для каждого файла с помощью команды fossil rename, перед выполнением команды addremove. Конечно, если вы не против нарушить историю редактирования определенных файлов, вы можете пропустить это и позволить fossil думать, что один файл был удален, а вместо него добавлен другой.

person Martijn    schedule 27.02.2014
comment
благодаря. Так что, если все, что я делаю, - это хочу отслеживать историю репо без каких-либо подтягиваний / толканий / обмена или чего-то подобного, тогда мне никогда не нужно закрывать, верно? Не могли бы вы прояснить одну вещь: могу ли я оставить открытыми несколько репозиториев? Спасибо! - person PatrickT; 27.02.2014
comment
Спасибо за совет по переименованию. Я действительно осознал, что fossil не догадывается, когда файлы были переименованы, и что я должен сообщить fossil об этом, но для меня это слишком много работы, и я лучше позволю репо увеличиваться в размерах, чем испытывать трудности, кроме неэффективность этого, это было бы нормально, правда? - person PatrickT; 27.02.2014
comment
Если я запускаю fossil open <project.fsl> --keep, я получаю Usage: fossil open REPOSITORY-FILENAME ?VERSION? Есть предложения? (Ничего, я просто все удалю и начну с нуля) - person PatrickT; 27.02.2014
comment
@PatrickT: Да, вы можете оставить открытыми несколько репозиториев (обычно в нескольких разных рабочих каталогах). fossil all list --ckout сообщает мне, что на моей машине 27 открытых рабочих каталогов. - person Martijn; 27.02.2014
comment
Если вы получили Usage: fossil open REPOSITORY-FILENAME ?VERSION?, это просто означает, что он не понимает, что вы набрали, и сообщает вам, чего он ожидает. Все, что написано ЗАГЛАВНЫМИ буквами, является заполнителем: вам нужно будет заменить его (в данном случае) именем файла вашего репозитория (и путем). Что-нибудь заключенное в? ВОПРОСЫ? является необязательным и поэтому может быть опущено. - person Martijn; 27.02.2014

arrow_upward
5
arrow_downward

Низкая церемония и легкое начало

Для одного разработчика жизненный цикл хранилища ископаемых может быть очень простым:

  1. fossil new для создания самого файла репозитория.
  2. fossil open для создания первой (или, возможно, единственной) активной рабочей области
  3. fossil add, fossil remove, fossil rename и fossil addremove, чтобы быть в курсе, какие файлы нужно отслеживать.
  4. fossil commit для фиксации изменений в репозитории

где шаги 3 и 4 повторяются по мере необходимости на протяжении всего жизненного цикла проекта.

Это одно из самых сильных преимуществ окаменелости: это очень низкая церемония по замыслу. Вы можете поддерживать очень сложный проект в одиночку и на самом деле использовать только fossil commit на регулярной основе.

Следующие шаги

Следующий этап изысканности может развиваться по нескольким направлениям. Если вы хотите поделиться работой над проектом со вторым разработчиком, вам нужно будет узнать больше о клонировании репозитория и синхронизации обновлений. Если вы хотите разрешить независимую работу над функцией, не нарушая сборки ствола, вы можете узнать больше о ветвлении и слиянии. Если вы хотите воспользоваться преимуществами функций вики и трекера билетов, вы захотите узнать о fossil ui, fossil server или настроить свой веб-сервер для запуска fossil.

Но ни один из этих вариантов использования не требует использования команды fossil close. Фактически, вывод fossil help недавно был разделен на более короткий список команд, необходимых большинству пользователей, и более длинный список всех команд. В том подразделении fossil close не вошли в короткий список. Единственные выполняемые им функции, которые не могут быть легко выполнены простым удалением файлов, - это проверка того, что их изменения не являются несохраненными, и удаление открытой проверки из вашего личного списка проверок, доступных для команды fossil all.

Словарь по ископаемым

Даже один разработчик захочет выучить часть словаря, используемого в документации fossil.

  • «checkin»: определенный набор ревизий файлов, идентифицируемых UUID и, возможно, одним или несколькими тегами.
  • "checkout": дерево папок, связанное (fossil open) с определенным репозиторием. Большинство команд fossil требуют, чтобы текущий каталог находился в открытой кассе.
  • «UUID»: уникальный идентификатор любой конкретной вещи, хранящейся в хранилище ископаемых. На практике UUID - это SHA-1 объекта, выраженный в шестнадцатеричном формате. В большинстве случаев UUID может быть сокращен до достаточного количества первых цифр полного хэша, чтобы однозначно идентифицировать его. Обычно это 8 или 10 цифр в квадратных скобках.
  • «артефакт»: файл или другой контент (вики-страница, билет, манифест и т. д.), хранящийся в репозитории. Каждый файл, который вы регистрируете, становится артефактом. То же самое со всеми метаданными (комментариями, отметками времени и т. Д.) О каждой проверке.
  • "branch": строка последовательных проверок, которая разветвляется от некоторой корневой проверки. Ветви используются для того, чтобы отложить изменения, пока они не будут готовы к слиянию, или просто для того, чтобы содержать изменения, которые являются ошибками.
  • "лист": отметка в конце ветки.
  • «ствол»: первая ветвь в любом репозитории называется «ствол». Большинство других ответвлений будут ответвлениями от некоторой отметки вдоль ствола.
  • «manifest»: список файлов, измененных при определенной регистрации, вместе с метаданными, описывающими эту регистрацию (пользователь, время, описание, UUID его родительской регистрации и любые теги, которые он может содержать) составляют манифест. Большинству пользователей действительно не нужно беспокоиться о манифестах, они создаются fossil commit и могут просматриваться через веб-интерфейс.

Веб интерфейс

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

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

Источники для получения дополнительной помощи

Помимо веб-сайта и отдельной справки по командам, доступной на fossil help, есть несколько других ресурсов, которыми должны пользоваться многие пользователи. в курсе.

Существует список ископаемых пользователей с постоянно высокое соотношение сигнал / шум. На это обращают внимание ключевые разработчики, как и многие полезные и знающие пользователи. В списке есть как минимум один архив, а также отдельный список для разработчиков, чтобы обсудить новые функции и планы, но fossil-dev не будет интересным, если вы не захотите поработать над внутренностью самого fossil.

У Джима Шимпфа есть книга, которая пытается быть одновременно учебным пособием и полным справочником, и включает несколько советов по передовому опыту. Это стоит прочитать.

Встроенная справка командной строки вместе с документацией для всех URL-адресов страниц, понятных веб-интерфейсу, также доступна в веб-интерфейсе fossil по адресу _ 19_ URL на любом сайте репозитория. Этот текст справки включает документацию по каждой команде, включая неподдерживаемые команды внутреннего тестирования.

И, наконец, [fossil tag] [tag] здесь, в StackOverflow, нельзя игнорировать как ресурс.

person RBerteig    schedule 04.03.2014
comment
@PatrickT, конечно, без проблем. Я просто счастливый пользователь. Я отредактирую ответ и добавлю ссылку в список рассылки, где тусуется много людей, включая основных разработчиков. - person RBerteig; 04.03.2014