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

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

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

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

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


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

Ответы [ 8 ]

4 голосов
/ 18 сентября 2009

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

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

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

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

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

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

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

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

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

3 голосов
/ 18 сентября 2009

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

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

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

1 голос
/ 18 сентября 2009

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

1 голос
/ 18 сентября 2009

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

  1. Если вы хотите «чистое» дерево исходных текстов, существует множество других функций, которые не включают уничтожение информации. Большинство систем контроля версий могут помещать элементы в удаленное состояние, которое скрыто от стандартных пользовательских интерфейсов (если вы не включите специальные параметры); применять разрешения на чтение для каждого элемента; переместить элементы в заранее определенную область дерева (например, в место, называемое «Старый материал»); или все вышеперечисленное.

  2. Насколько мне известно, каждая система SCC, достаточно мощная для поддержки пользовательских спецификаций просмотра, также позволяет администраторам проводить аудит и перезаписывать эти параметры.

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

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

1 голос
/ 18 сентября 2009

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

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

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

1 голос
/ 18 сентября 2009

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

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

0 голосов
/ 19 сентября 2009

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

...