2010-05-13 9 views
3

Я только начал использовать подрывную деятельность и прочитал официальную документацию (svn book), чит-лист и пару руководств. Я знаю, как установить subversion (в linux), создать репозиторий (svnadmin create) и импортировать проект Eclipse в репозиторий (импорт SVN), просмотреть файлы репозитория (используя список svn).Основные вопросы о Subversion

Но я не могу понять некоторые другие термины. Например, после импорта моего проекта Eclipse во вновь созданный репозиторий я внес изменения в проект Eclipse (более 1 файла). Теперь, как мне обновить репозиторий с помощью этих добавленных файлов/изменений, внесенных в проект Eclipse?

Команда обновления svn приносит изменения из репозитория в вашу рабочую копию - это противоположность тому, что я хочу, например, внести изменения, внесенные мной в проект Eclipse, в ранее импортированный проект в репозитории. Если я прав, вы чаще обновляете репозиторий (поскольку вы продолжаете расширять реализацию проекта), чем ваш текущий проект (с обновлением).

Кроме того, я не понимаю, когда вы используете svn merge. В svn-книге говорится, что он применяет различия между двумя источниками в рабочей копии. Есть ли сценарий, который бы объяснил это?

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

ответ

5
  1. Термин, который вы ищете, это «совершить».

  2. Subversion не только блокирует файл для редактирования (хотя есть команда сделать это, если вы действительно этого хотите). Таким образом, возможно, вам понадобится объединить наборы двух разных наборов пользователей в файл или даже редактировать из двух разных рабочих копий в двух разных местах на вашем компьютере.

  3. Несколько проектов в порядке. Лучший подход IMHO - это репозиторий/проект/соединительная линия и т. Д., А не репозиторий/магистраль/проект.

+0

Проблема с репозиторием/проектом/стволом заключается в том, что люди начинают добавлять проекты, зависящие от вашего проекта, а затем вы не можете проверить их все атомарно. Да, это случилось со мной. – orbfish

1

Вы commit изменения в хранилище

Merge полезен, когда вам нужно сохранить две ветви репозитория. Примеры v1.x с последними исправлениями безопасности и альфа-версией 2. Это позволяет делать исправления в коде 1.x, с результирующим двоичным кодом для существующих клиентов, и вы можете объединить изменения в версию 2, чтобы зафиксировать ошибок, которые еще не были пойманы.

1

Предлагаю вам ознакомиться с «типичными рабочими процессами svn». Они дадут вам общую картину «самых общих задач».

Что вы хотите сделать, это «зафиксировать» изменения, внесенные в ваши файлы в репозиторий.

Вам необходимо объединиться в случае конфликта (когда 2 или более человек работают над проектом и совершают одно и то же репо, могут возникнуть конфликты).

Проверяйте доступные статьи на SVN kai, чтобы не читать о образце/типичных рабочих процессах или рабочих сценариях с SVN.

1

Полностью согласен с Дэвидом, но, насколько вопрос 3 обеспокоен, лично я бы различать случаи использования:

  1. Производство: Один проект в хранилище. И погреться с указанной концепцией тега/стволом/ветвью, это действительно помогает много

  2. Тестирования: У меня есть один единый репозиторий, где я положил практически всех моих экспериментальным код (около 10 языков с й кодами. на каждый язык). Причина: Один экспериментальный код занимает меня 1-2 минут, создавая хранилище на удаленном хосте, используя SSH-безопасности иногда занимает больше времени ;-)

Приветствиях EL

2

Три вещи о вас СВН должен знать:

  1. Ствол - основная версия кода
  2. Метки - 'меткой' версии вашего кода (т.е. v1.2.5-релиз)
  3. Филиалы - Вилки кода для расходящихся путей развития. Обычно мы используем новые ветви для работы в разных версиях, поэтому, если текущая версия 1.2.4, вы должны перейти к разработке 1.3. Поэтому, если необходимо сделать аварийные изменения в 1.2 (т. Е. 1.2.5), вы можете работать над этим, не беспокоясь о том, что вы нарушили, добавив рефакторинг/функцию в свою ветвь 1.3. Операция merge спроектирована таким образом, что вы можете объединить ветвь 1.3 обратно в багажник, когда будете готовы к выпуску 1.3 или аналогичную операцию. Вы также можете объединить отдельные файлы (если два или более разработчиков отредактировали один и тот же файл одновременно, и теперь вам нужно «объединить» изменения в один и тот же файл.

Каждый проект в вашем репозитории должен иметь 3 папки в нем:

  1. /trunk
  2. /branches
  3. /tags

Эти три дома выше. Вам не нужно есть эти папки, но вы должны. Другие более зрелые VCS как у Mericual/Git есть понятия tags и branches, запеченные в системе. В SVN это скорее соглашение/рекомендация.

Терминология

  • Рабочая копия - копия на жестком диске, который содержит все ваши изменения, и т.д. ...
  • Add - Регистрирует файл для отслеживания в системе управления версиями
  • Update - Обновление working copy с изменениями от server repository
  • Commit - Обновляет server repository с изменениями от working copy
  • Switch - Заменяет working copy с другой папкой в пределах server repository
  • Diff - Дифференциальный анализ двух файлов/версий файла, чтобы увидеть изменения между ними.
  • Слияние - попытка применить изменения от одного или нескольких файлов к другому, выделяя конфликты.
  • Патч - набор различий, которые могут быть использованы для обновления файла.
Смежные вопросы