Потенциал для пропущенной версии в Subversion (исследовательская установка)

Question

Мой первый вопрос здесь, и я не видел его в другом месте. Я работаю в исследовательском институте, поэтому мы хотели бы сказать, какая версия кода дала определенный набор результатов. Мой вопрос состоит в том, является ли мой анализ правильным, как показано на иллюстрации ниже (обратите внимание, что идентификаторы узла версии предназначены только для иллюстративных целей и не соответствуют фактическим идентификаторам версии в SVN, Git или Hg. Номера версий с буквами представляют состояние незавершенного кода в SVN целые числа идентификаторов версий представляют зафиксированное состояние в SVN, все идентификаторы версий в поле Git / Hg представляют зафиксированное кодовое состояние):

Пример сценария:

• Предположим, что есть две рабочие копии "A" и "B", которые начинаются с версии 1.

• «A» изменяет значения по умолчанию в функции foo(), генерирует результаты и проверяет версию (repo ver2).

• «B» не пересматривает foo(), но какую-то другую часть кода, использует старые значения по умолчанию для генерации результатов и пытается зарегистрировать версию 1b, как использованную. Сбой из-за необходимости обновления, но в процессе объединения версий 2 и 1b SVN потеряет тот факт, что версия 1b использовала другие значения по умолчанию в foo(). Это не определяется как конфликт, поскольку «A» и «B» не изменили одну и ту же часть кода. Версия 3 не идентична версии 1b, поэтому возможность тиражирования не гарантируется.

Я не могу смоделировать этот сценарий на локальном диске с помощью TortoiseSVN (я не могу создать рабочие копии из-за ошибки извлечения SVN - «Невозможно открыть сеанс ra_local для URL»). Я точно знаю, что и Git, и Hg будут правильно обрабатывать ситуацию и показывать версию 1b в истории, если она была зафиксирована и если функция rebase не использовалась. (Я считаю, что rebase - это, по сути, нормальное поведение в SVN, когда ветки не задействованы.)

Является ли этот анализ правильным?

Answer 1

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

• A изменяет значения по умолчанию в foo() и повторно запускает эксперимент. Допустим, изменения влияют только на results/output-0001.dat.

• A фиксирует это как SVN ревизия 2.

• B пересматривает другую часть кода и генерирует новые результаты. Поскольку B не отличается от A, при перезапуске изменяется только results/output-1000.dat.

• B фиксирует это как SVN ревизия 3.

B может зафиксировать без обновления в первую очередь, поскольку сделанные им изменения не пересекаются с изменениями, сделанными A. Более того, редакция 3 SVN не соответствует рабочей копии на машине А или B! Если профессор C приходит и проверяет версию 3 SVN, он видит:

• results/output-0001.dat с результатами А и
• results/output-1000.dat с результатами B.

Это очень противоречиво.

Базовая концепция, которая допускает это, - рабочих копий смешанной ревизии . Subversion позволяет вам иметь файлы в различных ревизиях в вашей рабочей копии. Когда вы создаете редакцию 2 с изменением foo.c, этот файл помечается как находящийся в редакции 2. Другие файлы в рабочей копии остаются в редакции 1. Это позволяет вам выборочно обновить часть вашей рабочей копии обратно до старая редакция для целей отладки, и она позволяет фиксировать файлы без обновления, если никто не трогал файл.

Такие инструменты, как Mercurial и Git, не позволят вам сделать это, поскольку они моделируют историю как DAG (направленный ациклический граф). Каждое изменение становится новым узлом на графике, и вы должны сделать явный коммит слияния для объединения двух наборов изменений. В приведенном выше сценарии B попытается отменить изменения, а Mercurial прекратит работу. Затем он делает

$ hg pull
$ hg merge # he now has both his own and A's changes to the code
$ run-experiment
$ hg commit -m "Merge with new results"

Все три версии результатов теперь хранятся в истории.

Answer 2

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

У вашего рабочего процесса есть фундаментальная проблема: если вам нужна надежная идентификация результатов, вы сначала должен получить идентификатор, а , а затем дать результаты.Регистрируйся, потом генерируй.Если это вызывает проблемы с надежностью, зарегистрируйтесь в филиале, сгенерируйте результаты и затем объединитесь.Подход ветвления и слияния аналогичен тому, как работает распределенное программное обеспечение VCS, такое как git или hg, где локальные репозитории являются неявными ветвями, а push - неявным слиянием.