Имеет ли смысл постоянно удалять версии из VCS как часть обычного процесса разработки?

Мы используем ClearCase на моем рабочем месте. Часть нашего стандартного процесса, когда код объединен с основной (магистральной) ветвью, заключается в том, чтобы полностью искоренить все версии в ветвях разработки и интеграции. Поскольку это вытирает все комментарии, связанные с этими версиями, наши исходные файлы должны иметь длинный прологовый комментарий, который идентифицирует каждое изменение.

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

Обоснование, которое я слышал для удаления старых версий, как правило, сводилось к "хорошим" причинам. Мои более опытные коллеги считают, что удаление этих старых ветвей делает деревья версий для файлов "чище". Они утверждают, что нет никаких оснований хранить эти старые версии, как только они будут объединены с нашим сундуком. Они также обеспокоены тем, что другие разработчики случайно сохранят эти устаревшие ветки в своих представлениях конфигурации конфигурации. Наконец, они утверждают, что удаление этих ветвей сохраняет дисковое пространство на сервере CM.

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

Отредактировано для уточнения: предыдущие версии туловища всегда сохраняются. Это ветки, где материал изначально был создан или изменен, которые удалены.

Ответ 1

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

Часто, когда я сталкиваюсь с кодом, который выглядит странно, я хочу знать, как это получилось. Поскольку мы используем Subversion, я могу использовать "svn wame", чтобы найти, в какую ревизию появилась строка, и проверить ее оттуда. Это обычно приводит к пониманию цели кода и дает мне понять, что я могу сломать, изменив его. Также часто бывает полезно найти, когда функция была добавлена или удалена.

В то время как это может сэкономить некоторое пространство, хороший VCS будет хранить дельта и, следовательно, не будет занимать все лишнее пространство (примечание: я не знаю, хорошо ли ClearCase таким образом). Тем временем используемые вами файлы раздуваются комментариями пролога и, вероятно, кодом, который комментируется или условно скомпилирован, если он будет полезен позже.

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

Ответ 2

Если есть одна вещь, которую вы не делаете с ClearCase, это удаление версии.
Никогда. (Почти никогда).

ClearCase в значительной степени основана на дельта, его базовые линии могут быть установлены в инкрементном режиме, и для их правильного использования требуются предыдущие версии, и, как правило, история файлов - это то, о чем идет речь. (и история слияний: rmver удалит все xhlinks, т.е. все гиперссылки, такие как информация о слиянии)

Если вы действительно хотите очистить историю: cleartool lock -obsolete - правильный ответ.
Просто устарели старые ветки с туловища, которые вы больше не хотите видеть. Это обычно более чем достаточно.

Единственными случаями, когда удаление версии может быть оправдано, будет:

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

Ответ 3

Для меня не имеет смысла, почему вы использовали бы контроль версий, если вы не собираетесь хранить версии.

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

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

Ответ 4

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

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

Ответ 5

Нет никаких преимуществ при удалении информации о ревизии. Даже информация о ревизии без комментариев к проверке в 1000 раз лучше, чем информация о ревизии.

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

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

Ответ 6

Нет, я не думаю, что выгоды перевешивают затраты. Расходы очевидны (и хорошо освещены существующими ответами), поэтому я рассмотрю так называемые преимущества.

Если вы хотите "чище" исходное дерево, существует множество других функций, которые не связаны с уничтожением информации. Большинство систем управления версиями могут размещать элементы в удаленном состоянии, которые скрыты от стандартных пользовательских интерфейсов (если только вы не включаете специальные опции); применять разрешения чтения для каждого элемента; переместите элементы в предопределенную область дерева (например, в каком-то месте, называемом "Old Stuff" ); или все вышеперечисленное.
Насколько я знаю, каждая система SCC, достаточно мощная для поддержки специализированных спецификаций просмотров, также позволяет администраторам проверять и перезаписывать эти параметры.
Исходный код просто не такой большой. Особенно после того, как вы рассмотрите сжатие + дельта-хранилище. Только в нескольких приложениях с нишевыми приложениями, где задействованы большие двоичные файлы, я могу рассмотреть возможность постоянного удаления. (Например, студии разработки игр проходят через TON с изображениями высокого разрешения и видео.) Несмотря на это, моя политика хранения не была бы такой нахальной, как та, которую вы описываете. Я бы сохранил снимки с предопределенными интервалами. Скажите: все изменения в течение 2 недель, затем ежедневно в течение предыдущих 2 недель, еженедельно за несколько месяцев до этого, затем ежемесячно возвращаются к началу.

Нижняя линия, время разработчика действительно дорого. Несколько минут администрирования CC + несколько дополнительных жестких дисков в SAN даже не сравниваются.

Ответ 7

Возможность Обвинять кто-то для конкретного изменения часто очень полезен. Как только все изменения в багажнике, вся информация о том, кто написал и почему он это сделал, потерян. Возможность показать кому-то, что "Здесь - вы сделали это, там" часто очень полезно в себе, даже без комментариев коммита.

Ответ 8

Без истории управления версиями очень полезный инструмент "отладки", поиск истории для ошибки (путем деления пополам), чтобы найти первую ревизию, которая ввела ошибку, невозможен. Когда вы обнаружите коммит, который ввел ошибку (некоторые VCS предоставляют команду "scm bisect", чтобы помочь в этом, даже до полной автоматизации, если у вас есть сценарий теста), и вы следовали за хорошими методами управления версиями небольших, одиночных выпусков, хорошо описанных коммитов, то очень легко найти, где ошибка.