VCS поддерживает файлы версий для каждого пользователя

Question

Я уже использовал некоторые VCS, такие как CVS, SVN и Git.Одна функция, которую мне не хватает, нигде не может быть найдена.

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

Зачем мне это нужно?Есть некоторые файлы, такие как конфигурация, где я хотел бы иметь версию по умолчанию в репозитории (например, для создания выпусков или стартовой базы для новых членов команды), но изменения в этом файле относятся только к определенному разработчику (или рабочей копии)потому что он будет содержать пути, действительные только для этого разработчика / рабочей копии.

В настоящее время, когда я не добавляю эти файлы: - Я скучаю по ним при создании новой рабочей копии или экспорте для сборки выпуска - Нет истории, котораяизменения, которые я мог бы сделать для себя, чтобы поэкспериментировать

В настоящее время, когда я добавляю эти файлы в хранилище: - Я мог бы никогда не зафиксировать их, поэтому у меня есть значение по умолчанию в хранилище, но мой файл всегда помечается как «измененный».В SVN я могу добавить его в список изменений "ignore-on-commit", чтобы немного улучшить.- Я могу потерять свои собственные изменения в сложном файле конфигурации (сбой данных, кража ноутбука и т. Д.)

Есть ли VCS, способная на это?Поддерживает ли SNV или git что-то, что я мог наблюдать?

Answer 1

Если я понял и разложил Ваша задача правильно

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

вы можете использовать этот рабочий процесс (черновик, предмет изменений и исправлений), основанный на Subversion для простоты и прозрачности управления (сильная сторона любого CVCS на самом деле)

• хранилище Subversion
• Каждый пользователь репо имеет собственный предопределенный путь внутри дерева репозитория (с общим шаблоном пути для управляемости и простоты автоматизации процессов)
• Существует также один специальный управляемый только для администратора путь, недоступный для обычных пользователей

Наше дерево может выглядеть так (где Repository dir является корнем хранилища)

z:\>dir /s /B
z:\Repository
z:\Repository\Users
z:\Repository\Template
z:\Repository\Users\Alpha
z:\Repository\Users\Bravo

• Для каждого пути пользователя мы используем Аутентификацию на основе пути, которая предоставляет доступ каждому и каждому пользователю только к собственному поддереву в репозитории,
• Шаблон содержит (как предполагает название) шаблоны заглушек для всех документов пользователя
• Добавление новых пользователей в репо, очевидно, становится простой и легкой автоматизированной задачей:
  • svn copy Шаблон в каталог нового пользователя
  • добавить права доступа для созданного местоположения для пользователя в authz-файле
  • сообщить пользователю URL своего личного дерева в репо

Answer 2

Я не думаю, что проблема здесь в VCS.Похоже, если у вас есть файл, содержимое которого зависит от локальной среды, вы должны автоматически сгенерировать его с помощью скрипта.Таким образом, вы игнорируете сгенерированный файл, но версия сценария и каждый разработчик по-прежнему получают совершенно правильную копию файлов конфигурации во время выполнения.Это тот же подход, который используется, например, с пользовательскими настройками среды IDE: например, файлы .suo в Visual Studio.

Обновление:

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

1. Добавьте значения по умолчанию в хранилище.
2. Каждый разработчик работает в своей собственной ветке.Таким образом, они могут вносить изменения в файлы конфигурации.
3. При повторном использовании мастера и / или слиянии разработчики просто никогда не объединяют свои настроенные конфигурации.
4. Вы всегда можете настроитьловушка, чтобы проверить, была ли изменена конфигурация по умолчанию, и если так, возможно, отправьте электронное письмо разработчику.Вы просто просматриваете такой коммит так же, как вы просматриваете коммит, который не компилируется.

Разработчики умны.Конечно, они делают ошибки.Но никогда не стоит недооценивать силу простого общения.

Конечно, когда конфиги по умолчанию перезаписываются настроенными в Dev X, вы используете возможности git для немедленного исправления этого коммита.