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