Любые технические проблемы с длинными номерами версий CVS? - PullRequest
Новая
       24

Любые технические проблемы с длинными номерами версий CVS?

3 голосов
/ 11 января 2010

Наш проект имеет историю создания новых веток в CVS из существующих веток. Через несколько лет это привело к такой ситуации с файлами, которые меняются в каждом выпуске:

новая редакция: 1.145.4.11.2.20.2.6.2.20.2.1.2.11.2.3.2.4.4.4.2.5.2.1.2.1.2.6.2.23;
предыдущая редакция: 1.145.4.11.2.20.2.6.2.20.2.1.2.11.2.3.2.4.4.4.2.5.2.1.2.1.2.6.2.22

Очевидно, что это выглядит плохо в консоли CVS, но имеет ли это техническое значение? Получим ли мы что-нибудь, объединив все обратно в голову, чтобы оно вернулось в 1,146?

(П.С. «Переключиться на подрывную деятельность» не является ответом.)

Ответы [ 3 ]

3 голосов
/ 11 января 2010

Очевидно, это работало для вас в течение нескольких лет, поэтому, если есть технические проблемы, то вы их еще не видели. Я не знаю ни о чем, с чем вы столкнетесь; однако, если это продолжится в течение следующих нескольких лет, я не удивлюсь, если вы начнете находить ограничения и ошибки в различных инструментах. (Не говоря уже о том, что вы никогда не сможете соответствовать рекомендациям по длине строки исходного кода.: P)

Получим ли мы что-нибудь, объединив все обратно в голову, чтобы оно вернулось в 1,146?

Ясность . С более простой системой легче работать, даже если более сложный эквивалент технически обоснован. Есть ли что-то, что можно потерять, вернувшись к 1.146? На этом этапе вы говорите о преимуществах для проектов и групп, ценность которых будет варьироваться, и вам просто нужно решить, стоит ли затраченный результат.

1 голос
/ 24 января 2010

Получим ли мы что-нибудь, объединив все обратно в голову, чтобы оно вернулось в 1,146?

Есть несколько аргументов для слияния:

  • Удобство - проще ссылаться на более короткие номера ревизий, чем на абсурдно длинные. Но необычно ссылаться на редакции CVS по номерам, потому что номера редакций не одинаковы для разных файлов, поэтому это преимущество незначительно.

  • Производительность. Способ, которым CVS хранит дельты ревизий, оптимизирован для работы с ревизиями на кончике HEAD (см. Rcsfile (5)). Если время, необходимое для проверки и других операций CVS, становится недопустимым, может помочь объединение основной линии разработки с HEAD.

  • Предотвращение ошибок инструментов - вполне вероятно, что какой-то инструмент, с которым вы работаете (CVS? Инструменты уведомлений о фиксации? Веб-просмотрщик? Плагин IDE?), Имеет встроенные ограничения на размер номеров ревизий, которые он использует может иметь дело с. Если вы сталкиваетесь с такими ошибками, вы можете быть вынуждены изменить свой стиль, хотите вы этого или нет.

Но есть несколько существенных недостатков слияния, которые вы не должны забывать:

  • Учитывая, что CVS не записывает информацию о слияниях, слияние разработок может привести к потере истории изменений, ведущих к новой "текущей" версии. Например, cvs log больше не будет сообщать вам последовательность изменений, которые привели к текущей ревизии.

  • Если вы не измените процесс разработки, ваша кодовая база снова начнет прорастать по ветвям, что сделает любые выгоды временными. (И наоборот, если вы планируете изменить процесс разработки одновременно, слияние обратно в голову будет более оправданным.)

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

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

0 голосов
/ 11 января 2010

Ограничение размера для CVS, вероятно, будет зависеть от конкретной реализации CVS, которую вы выбрали. Это конкретное приложение установило бы максимальный размер строки для номера версии. Я не могу себе представить, что это будет намного выше, чем 50 или 100, но это не главное. Несмотря на то, что вы могли бы избежать использования такой длинной строки номера версии, это не рекомендуется.

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

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

Поскольку каждое число после десятичной точки обозначает уровень значимости изменения, вам действительно нужно всего лишь 4 или 5 периодов максимум. В противном случае это свидетельствует о том, что ваши циклы сборки программного обеспечения СЛИШКОМ ДЛИНЫ или вы просто злоупотребляете соглашениями о номерах версий. Я бы придерживался 4 или 5 периодов, макс.

Это должно выглядеть примерно так: <основная версия>. <Полуосновная версия версии>. <Версия выпуска>. <Номер сборки>, что приводит к чему-то вроде 4.2.12.45, если вы работаете над версией продукта 4 ( это почти то, что вы показываете пользователю), и это был второй большой релиз, потому что произошли значительные изменения в том, как работает 4, но он все еще работает, как должно было работать 4, а 12-я версия с исправлениями ошибок, обновлениями безопасности и т. д. И, наконец, 45-я сборка разработки во время тестирования перед выпуском 4.2.12. Это всего лишь пример, но что-то вроде этого работает очень хорошо.

...