#svn #version-control #revision
#svn #контроль версий #пересмотр
Вопрос:
Я использую subversion для отслеживания набора файлов и хотел бы перенести ключевые слова ревизии в рабочий процесс. Но я сталкиваюсь с некоторыми проблемами из-за способа настройки.
Рабочий процесс следует этому формату:
- Текстовый файл (svn: ключевые слова включены), который импортируется в;
- Файл типа Xml, содержащий ключевые слова, импортированные из текстового файла. Затем этот скрипт запускается и выдает другой;
- Файл типа Xml, который в идеале содержит информацию о ревизии как 1, так и 2.
Требования к ревизиям файлов составляют 1 < 2 < 3, а ревизия 1 отображается в 2, а ревизии 1 и 2 отображаются в 3.
Таким образом, проблема возникает в файле 2, где я, очевидно, не могу включить svn:keywords, поскольку это перезапишет запись из файла 1 при ее фиксации.
В идеале я хотел бы иметь разные ключевые слова, зависящие от типа файла, но, похоже, это невозможно в SVN.
Я изучил перехваты до / после фиксации, но, насколько я понимаю, без использования разных ключевых слов это не помогло бы.
Я подумал о возможном решении, в котором я бы ввел некоторые ключевые слова в файл 1, которые должны быть уникальными для файла 2. Затем, когда я фиксирую файл 2, я бы написал небольшой скрипт, который ищет эти ключевые слова и заполняет эти записи аналогичной информацией (т.е. упреждает номер редакции, проверяя номер редакции репозитория, добавляет его и помещает в файл 2, а затем фиксирует его). Однако для этого требуются внешние скрипты, которые не являются проблемой для разработки, но я бы хотел сохранить их в SVN, если это возможно.
Есть ли какой-нибудь способ добиться этого, используя только SVN?
Чтобы было ясно, я не хочу и не забочусь о том, чтобы в файле был номер редакции файла 3, если присутствуют ревизии файлов 1 и 2.
Спасибо за вашу помощь!
Ответ №1:
Боюсь, но, похоже, вы сделали некоторые неправильные предположения и не отладили свой рабочий процесс
- Даже в старом SVN до 1.8 (который добавил «пользовательские ключевые слова», которые могут эмулировать ключевое слово для каждого типа файла), которые я в любом случае не рекомендую использовать сегодня, расширенные ключевые слова, вставленные в другой версионный объект, больше не будут «расширяться»
- С 1.8 SVN вы можете иметь набор ключевых слов с разными именами, но с одинаковым значением
%r, но в вашем случае это просто не нужно
Подробные сведения:
Когда вы добавляете ключевое слово $Rev$ в версионный файл (и выполняете корректно svn propset svn:keywords или включаете расширение в конфигурации), после цикла фиксации / обновления вы увидите в своем WC в файле что-то вроде $Rev: 12 $ вместо просто заполнителя ключевого слова, и эта строка, вставленная в любой другой источник, будет использоваться «как есть», а не какеще одно размещение ключевых слов в целевом файле
Комментарии:
1. Спасибо за информацию, ленивый Барсук! Насколько мне известно, это проясняет некоторые вещи. Однако конкретный случай, который у меня есть (из приведенного выше рабочего процесса), требует, чтобы ключевые слова для файла 2 должны быть встроены в файл 1. Итак, кажется, что я могу использовать пользовательские ключевые слова для 2 типов файлов и иметь как «стандартные» ключевые слова для файла 1, так и пользовательские в файле 2. Я пытался сделать это с помощью svn:auto-props, но, похоже, не могу заставить пользовательские ключевые слова работать для 2-го файла (они даже не отображаются, когда я проверяю, какие свойства имеет файл). Да, я удалил / добавил 2-й файл, чтобы включить новые автоматические реквизиты.
Ответ №2:
Итак, я смог разобраться в этом особом случае. В общей папке я установил svn:auto-props для двух типов файлов, например, *.txt = svn:keywords=Автор редакции * .xml = svn:keywords=XMLRevision=%r XMLAuthor=%a Теперь у меня есть оба набора ключевых слов в первом файле, где первыйset выбирается при фиксации текстового файла, а второй — при фиксации xml. Оба набора также отображаются в третьем файле. Примечание: можно было установить автоматические реквизиты из браузера репозитория, но, похоже, это не сработало. Проверка общей папки и выполнение ее из рабочей копии сделали свое дело. Примечание 2: очевидно, также пришлось удалить файл 2 (xml) из репозитория и добавить его снова, чтобы он получил новые автоматические реквизиты.