Имеет ли смысл окончательно удалять версии из VCS как часть обычного процесса разработки?
Мы используем ClearCase на моем рабочем месте. Частью нашего стандартного процесса, когда код объединяется с основной (магистральной) веткой, является полное уничтожение всех версий в ветвях разработки и интеграции. Поскольку это приводит к удалению всех комментариев о регистрации, которые сопровождали эти версии, наши исходные файлы должны иметь длинный прологический комментарий, который идентифицирует каждое изменение.
В нескольких случаях я указывал, что это сводит на нет одну из фундаментальных причин использования системы контроля версий, и заявлял, что, удаляя версии, становится невозможно увидеть, кто первоначально работал над чем-то, когда возникли проблемы и т. Д. Люди, проверяющие новые версии научились не беспокоить ввод комментария о регистрации, потому что он все равно будет удален.
Оправдание, которое я слышал об удалении старых версий, обычно сводится к причинам "хорошего самочувствия". Мои более опытные коллеги считают, что удаление этих старых веток делает деревья версий файлов более "чистыми". Они утверждают, что нет никакой причины хранить эти старые версии, как только они будут объединены с нашим стволом. Они также обеспокоены тем, что другие разработчики случайно сохранят эти устаревшие ветви в своих спецификациях конфигурации представления. Наконец, они утверждают, что удаление этих ветвей экономит дисковое пространство на сервере CM.
Правильно ли у меня сложилось плохое предчувствие по этому поводу, или есть другие магазины, которые успешно работают таким образом? Если вы также считаете, что это плохая идея, какие еще аргументы в пользу сохранения старых версий вы бы предоставили? Если вы успешно работали с такого рода процессами, какие преимущества вы наблюдали?
Отредактировано для уточнения: предыдущие версии багажника всегда сохраняются. Это ветки, в которых материал изначально был создан или изменен, которые удалены.
8 ответов
Вы уже заметили одну большую проблему: с удалением комментариев коммитов нет автоматической записи того, как код должен быть таким, какой он есть. Также нет способа изучить историю того, как программное обеспечение стало таким, каким оно было: это один большой кусок с большими прологическими комментариями, которые могут быть или не быть точными.
Часто, когда я сталкиваюсь с кодом, который выглядит странно, я хочу знать, как он появился. Так как мы используем Subversion, я могу использовать "svn blame", чтобы найти, в какой ревизии появилась строка, и проверить ее оттуда. Обычно это приводит к пониманию цели кода и дает мне подсказку, что я могу сломать, изменив его. Также часто полезно узнать, когда функция была добавлена или удалена.
Хотя это может сэкономить некоторое пространство, хороший VCS будет хранить дельты и, следовательно, не будет занимать столько много дополнительного пространства (примечание: я не знаю, хорош ли ClearCase таким образом). В то же время, файлы, которые вы используете, разбухают от комментариев пролога и, вероятно, от закомментированного или условно скомпилированного кода на случай, если это понадобится позже.
У кого-то, кто раньше управлял системой VCS, есть только две причины удалить что-то из системы. Во-первых, если что-то зафиксировано, чего не должно быть, и это вызывает проблемы (например, они могут быть очень большими - у некоторых людей возникают проблемы, когда кто-то фиксирует не только исходные файлы, но и все двоичные файлы), а другой - если это неуместно (например, конфиденциальная информация).
Если есть одна вещь, которую вы не делаете с ClearCase, это удаление версии.
Никогда. (Почти никогда так или иначе).
ClearCase в значительной степени основан на дельте, его базовые показатели могут быть установлены в инкрементном режиме, и для правильного их содержимого потребуются предыдущие версии, а в целом история файлов - это то, о чем идет речь. (и история слияний: rmver удалит все xhlinks, т.е. все гиперссылки, такие как информация о слиянии)
Если вы действительно о чистке истории: cleartool lock -obsolete это правильный ответ.
Просто устаревшие ветки из ствола вы больше не хотите видеть. Обычно этого более чем достаточно.
Единственные случаи, когда удаление версии может быть оправдано:
- новые версии с "неправильным содержимым", которые вы вообще не имели в виду: если это последняя версия, без метки или гиперссылок, вы можете удалить ее, а не изменить…
- большие двоичные файлы развиваются очень часто (тогда
rmverдля старых версий может реально сэкономить место). Все остальные типы файлов не сохранят значительного места, если удалить их старые версии.
Для меня не имеет смысла, почему вы используете контроль версий, если не собираетесь сохранять версии.
Основным преимуществом контроля версий, на мой взгляд, является возможность вернуться во времени. Я постоянно проверяю предыдущие версии файлов, чтобы выяснить, почему или как что-то изменилось.
Это стало особенно удобно, так как требования развиваются, и вы обнаружите, что вам действительно нужен код, который вы написали три месяца назад.
Удаление информации о ревизии не дает никаких преимуществ. Даже информация о ревизиях без комментариев о регистрации в 1000 раз лучше, чем информация о ревизиях.
Наиболее убедительным аргументом в пользу сохранения информации о ревизиях (помимо восстановления файлов) является то, что, когда вы обнаруживаете ошибку и отслеживаете возврат к месту регистрации, где ошибка была введена, обычно хорошей идеей является поиск проверок одним и тем же пользователем в одно и то же время., Ошибка может быть более обширной, чем кажется на первый взгляд. Не могу сделать это без информации о ревизии.
Сменить работу. Вы будете жить дольше. Работа с программистами, которые не понимают преимуществ контроля версий, не может быть полезной для вашего здоровья.
Удаление версий мне непонятно. Похоже, ваши коллеги пытаются защитить идиотом использование ClearCase, а не предоставлять надлежащую документацию, поддержку и обучение по его возможностям.
К сожалению, я тоже столкнулся с очень похожими ситуациями. При запуске будущих проектов вы должны попытаться привести ясные и ясные аргументы о том, как, по вашему мнению, должен осуществляться контроль версий. Возможно, если процесс, с которого начинается проект, установлен правильно, они все увидят преимущества и применят их к будущим проектам.
Возможность обвинять кого-то в определенных изменениях часто очень полезна. После того, как все изменения находятся в стволе, вся информация о том, кто что написал и зачем он это сделал, теряется. Возможность показать кому-то, что "Здесь - Ты сделал это, там" часто очень полезна сама по себе, даже без комментариев коммитов.
Нет, я не думаю, что выгоды перевешивают затраты. Затраты очевидны (и хорошо отражены в существующих ответах), поэтому я рассмотрю так называемые преимущества.
Если вы хотите "чистое" дерево исходных текстов, есть множество других функций, которые не включают уничтожение информации. Большинство систем контроля версий могут помещать элементы в удаленное состояние, которое скрыто от стандартных пользовательских интерфейсов (если вы не включите специальные параметры); применять разрешения на чтение для каждого элемента; переместить элементы в заранее определенную область дерева (например, в место, называемое "Старый материал"); или все, что выше.
Насколько мне известно, каждая система SCC, достаточно мощная для поддержки пользовательских спецификаций просмотра, также позволяет администраторам проверять и перезаписывать эти параметры.
Исходный код просто не такой большой. Особенно после рассмотрения сжатия + дельта-хранилища. Лишь в нескольких нишевых приложениях, где задействованы большие двоичные файлы, я мог бы рассмотреть возможность постоянного удаления. (Например, студии разработки игр проходят через тонну иллюстраций и видео высокого разрешения.) Несмотря на это, моя политика хранения не была бы такой дерзкой, как та, которую вы описываете. Вместо этого я бы сохранял снимки с заданными интервалами. Скажем: все изменения за 2 недели, затем ежедневно в течение предыдущих 2 недель, еженедельно в течение нескольких месяцев до этого, затем ежемесячно назад к началу.
Суть в том, что время разработчика действительно чертовски дорого. Несколько минут администрирования CC + несколько дополнительных жестких дисков в SAN даже не сравниваются.
Без истории контроля версий очень полезный инструмент "отладки", поиск истории ошибок (путем деления пополам), чтобы найти первую ревизию, в которой была обнаружена ошибка, невозможен. Когда вы обнаруживаете коммит, который привел к ошибке (некоторые VCS предоставляют команду "scm bisect", чтобы помочь с этим, даже вплоть до полной автоматизации, если у вас есть тестирование по сценарию), и вы следовали хорошей практике контроля версий небольшой, единственной проблемы, хорошо описанной фиксации, тогда очень легко найти, где ошибка.