Есть ли способ «запутать» два файла в Subversion?

Question

У меня есть следующая проблема, с которой сталкивались другие люди. Я работаю над базой кода, которая работает на двух разных платформах. Большая часть кода распределяется между платформами, но некоторые части кода оптимизированы для конкретной платформы. Таким образом, может быть общая реализация функции foo() в файле foo.cpp и реализация, оптимизированная для платформы A в файле foo_A.cpp.

Конечно, иногда случается, что разработчик изменяет foo.cpp и забывает внести соответствующее изменение в foo_A.cpp, чтобы поддерживать их синхронизацию. Это приводит к очень неприятным ошибкам, которые трудно отследить.

Наконец, вот мой вопрос: есть ли способ «запутать» два или более файлов в Subversion? Возможно ли, когда кто-то вносит изменения в foo.cpp, svn выдает предупреждение, напоминание об обновлении foo_A.cpp?

Answer 1

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

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

Answer 2

Subversion имеет крючки, которые вы можете использовать. По сути, вы пишете скрипт в нужной папке и с правильным именем. Он может проверить, зарегистрирован ли файл с определенным именем, а затем выполнить несколько действий в ответ. (Другими словами, вы можете автоматизировать обновление одного файла каждый раз, когда регистрируется другой файл.)

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

Answer 3

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

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

В качестве альтернативы вы можете попытаться решить проблему в процессе сборки,Сценарий сборки может выполнить «svn info» для двух файлов, а затем выдать предупреждение / ошибку, если номера версий SVN двух файлов не совпадают.Однако может быть трудно определить, отличаются ли числа оборотов по законным причинам (например, вы сознательно отредактировали только один из файлов).пытаясь решить проблему неправильно.Я бы попытался структурировать код, чтобы предотвратить появление этого класса ошибок.Если обе функции необходимо изменить одновременно, это является признаком ненужного дублирования в кодовой базе.Посмотрите на объединение общих элементов двух файлов в одном месте.

Answer 4

Поскольку вы используете скомпилированный язык, рассматривали ли вы просто написание #ifdef (проверяющих флаги, определяющие платформу) в функциях оптимизации вместо простого написания совершенно новой функции?

Answer 5

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