Добавление неверсионных файлов в Subversion

Question

Возможно ли добавить файлы в Subversion, которые не должны быть версионными? F.ex. config-файлы, которые должны быть отредактированы для соответствия каждой отдельной среде. Когда новый программист подключен к проекту, он должен получить исходный файл из Subversion, но он не будет зафиксирован после того, как он его отредактирует, и он не будет перезаписан при обновлении.

Может быть, создание тега для всего оригинального проекта - это решение? Сначала скачать тег, а затем обновить из транка?

Есть идеи?

---

Пояснения к комментариям ниже: Проект (Sitecore) состоит из около 30 тысяч различных файлов. Нам нужно версия около 100 из них. Если мы должны включить все файлы в управление версиями, то каждый коммит занимает вечность (так как черепаха просматривает все папки). Сегодня мы создаем zip-файл, содержащий все неверсионные папки, устанавливаем папки как игнорируемые в svn, а затем добавляем zip. Проблема в том, что когда нам нужно изменить один или несколько файлов в zip-архиве, нам нужно добавить новый ~ 1GB-zip в репозиторий.

Answer 1

Я бы разместил неверсионные файлы на веб-сервере или файловом сервере, доступном для всех, кто использует проект, и добавил сценарий для автоматической (wget / scp / и т. и извлеките их в svnignored папки, чтобы они не были обнаружены Subversion.

Если вас беспокоит изменение этих файлов, то: не должны ли они быть версионными?

svn: externals также может пригодиться в этой ситуации. Я думаю их можно настроить так, чтобы их можно было легко игнорировать, если позволяют обстоятельства.

Answer 2

В некоторых случаях даже нет необходимости создавать web.config для разработчика, поскольку формат конфигурации .Net позволяет переопределять определенные разделы вашего файла конфигурации через атрибут configSource.

Атрибут configSource указывает имя файла, которое (если файл существует) переопределяет указанный блок, а когда он не существует, блок используется как есть.

<?xml version="1.0"?>
<configuration>
  <connectionStrings configSource="connections.config">
      <add name="LocalSqlServer" 
           connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
           providerName="System.Data.SqlClient" />
  </connectionStrings>
</configuration>

В системе разработчика вы можете просто добавить файл connections.config с подключениями для него, а остальные настройки можно использовать совместно.

(Таким образом, это не решает проблему с шаблонами, но может помочь вам управлять большим шаблоном и большим количеством маленьких)

Answer 3

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

Answer 4

Вам нужно переосмыслить, как вы используете subverion. Subversion хранит информацию о версии файлов; Не больше, не меньше. Вы не можете хранить неверсионные файлы в Subversion; не имеет никакого смысла. Хранение zip-файла размером 1 ГБ в subversion также не принесет ничего хорошего.

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

Answer 5

Просто используйте для этого файл-шаблон. Предположим, ваш файл называется config.txt. Посмотрите на файл и вставьте некоторые маркеры, куда должны идти локальные настройки, переименуйте его в configTemplate.txt и зафиксируйте его. Затем каждый разработчик должен проверить файл, сделать его копию, удалить часть шаблона имени файла (чтобы каждый получил правильный файл config.txt) и добавить новый файл в список игнорирования. Затем либо пусть все просто вручную редактируют в локальных настройках, где маркеры находятся в файле шаблона, либо используют скрипт для них (если это возможно).

Файл шаблона никогда не изменяется (если, конечно, нет разницы в формате файла конфигурации).

В ответ на ваше редактирование (и комментарий):

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

Answer 6

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