Как игнорировать определенные подкаталоги Subversion во время коммита

Question

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

project/src             # Here is the location of the source code
project/src/more_src    # Some more source code lives here
project/src/bin         # Here are the binary files

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

Я пользователь командной строки в Subversion. Я хотел бы игнорировать каталог bin, чтобы при использовании svn st и svn ci эти каталоги пропускались (даже если есть ожидающие изменения).

К сожалению, я не могу использовать -N (не рекурсивный) из-за каталога more_src.

Как мне это сделать?

Answer 1

edit : Subversion 1.6 была выпущена. Из заметок о выпуске:

В Subversion 1.6 --setset глубина параметр для обновления SVN вырос новое значение - исключить. Это значение говорит Subversion для исключения цели из рабочая копия, сразу и до дальнейшего уведомления. До Subversion 1.6, если каталог может не легко быть удаленным из рабочего копия. ...

Все, что ниже, сейчас устарело.

---

Вы можете ограничить глубину папок в вашей рабочей копии в нужных местах, чтобы нежелательные файлы не отображались как версионные файлы. Вы не можете уменьшить глубину в существующей рабочей копии.

1) Оформить чистую рабочую копию, как эта (она будет содержать только файлы и пустые папки в корневом каталоге):

svn co --depth немедленный repoURL / Некоторые / туалет / путь

2) Теперь для каждой папки, которую вы не хотите игнорировать, извлеките содержимое с помощью

svn update --depth infinity /some/good/path

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

svn update --depth immediates /some/path/to/make/deeper

Этот подход имеет недостаток. Если игнорируемые файлы появляются в вашей рабочей копии в результате ваших собственных действий (например, сборки), они будут отображаться в статусе svn как неверсированные файлы. Вы даже можете svn добавить их и вызвать ошибки «файл уже существует».

---

edit: Видимо, вы МОЖЕТЕ уменьшить глубину частей вашей рабочей копии, что намного проще:

1. нормальная проверка проекта (или начало из существующей рабочей копии)
2. удалить нежелательную папку (нормально удаление файловой системы, а не svn rm). На данный момент папка отсутствует и вернется со всем ее злым содержанием, если вы сделали нормальное обновление.
3. вернуть папку с

svn update --depth empty / Путь / где / удален / папка / был

Теперь вы можете выполнить svn-обновление всего проекта, но плохое содержимое не вернется.

Answer 2

Обычно вы хотите сохранить только двоичные файлы, которые были выпущены явным образом, то есть официальные выпуски или двоичные файлы, которые используются отделом тестирования. Так что на самом деле нет смысла фиксировать каждый недавно созданный двоичный файл.

Таким образом, реальное решение вашей проблемы - это редизайн вашего SVN-репозитория. Каталоги, в которых собраны файлы, не должны находиться под контролем исходного кода И должны игнорироваться с использованием свойств svn: ignore. Это препятствует тому, чтобы недавно собранные двоичные файлы были замечены SVN. Во-вторых, вы можете создать отдельный каталог, в котором вы храните двоичные файлы, которые вы хотите сохранить. Этот каталог, разумеется, должен находиться под контролем версий.

Теперь вы можете развиваться, не беспокоясь о смене двоичных файлов. Когда вы, наконец, дойдете до стадии, на которой вы хотите сохранить эти двоичные файлы, вы просто копируете эти двоичные файлы в отдельный созданный выше каталог, перезаписывая старые SVN теперь заметит, что файлы изменились, и вы можете их зафиксировать.

Другой подход, который я видел в прошлом, - это сначала создать тег из вашего исходного дерева. Затем сервер сборки (или вы сами) извлекает этот тег и создает двоичные файлы из этого извлеченного тега. После этого встроенные двоичные файлы фиксируются поверх этого тега. Многие люди думают, что вы никогда не должны делать коммиты поверх TAG, но это может сработать для вас. Единственное, о чем вы должны помнить, это то, что при экспорте / проверке этой TAG вы должны принять ревизию HEAD, а не собственную ревизию TAG (которая будет HEAD-1).

Answer 3

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

У меня похожий сценарий, и у меня есть несколько псевдонимов:

alias up-all='svn up ~/includes ~/scripts ~/htdocs/intra ~/htdocs/update'

Если вы работаете в Windows, вы можете объединить некоторые .bat или другие сценарии и поместить их в свой путь для достижения тех же результатов.

Answer 4

Еще одно важное примечание, которое нужно добавить к вышесказанному (скопировано с http://svnbook.red -bean.com / nightly / en / svn.advanced.props.special.ignore.html ):

Поддержка Subversion для шаблонов игнорируемых файлов распространяется только на до одноразового процесса добавления неверсионных файлов и каталогов в систему управления версиями. Когда объект находится под контролем Subversion, механизмы шаблонов игнорирования больше не применяются к . Другими словами, не ожидайте, что Subversion избежит внесения изменений, которые вы внесли в версионный файл, просто потому, что имя этого файла соответствует шаблону игнорирования - Subversion всегда замечает все свои версионные объекты.

Answer 5

Если они контролируются версией, тогда Subversion делает свое дело:)

Подход wcoenen также должен выполнить эту работу после небольшой работы, другим подходом может быть скрипт, который выполняет svn revert / project / src / bin, а затем svn ci.

Для чего бы это ни стоило, это одна из причин, по которой мы устанавливаем каталог "deploy" и всегда игнорируем вывод каталога bin и obj. Таким образом, только в определенных сборках релиза двоичный вывод копируется (и добавляется в svn) для развертывания.