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

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

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 каталога.

Как я могу этого добиться?

Ответов (5)

Решение

редактировать : была выпущена subversion 1.6. Из примечаний к выпуску:

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

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


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

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

svn co --depth немедленно указывает repoURL / some / wc / path

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-обновление всего проекта, но плохой контент не вернется.

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

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

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

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

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

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

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

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

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

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

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

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

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