Что самое раздражающее в используемой вами системе контроля версий (SCM)?
Этот вопрос не спрашивает, какое программное обеспечение контроля версий я должен использовать. Скорее, я хотел бы услышать, что вы думаете о минусах некоторых из используемых вами СКМ.
Веб-сайты и маркетинговые материалы только подчеркивают преимущества, но я хочу услышать от людей, которые действительно использовали его, что они считают недостатками.
Можете ли вы назвать какое-то качество или поведение, которое вы считаете раздражающим или контрпродуктивным в SCM, который вы используете или использовали?
13 ответов
В моих последних двух работах мне было необходимо использовать IBM Rational ClearCase, и подсчет путей, которыми этот несовершенный и расстраивающий пакет подрывает мое желание жить ежедневно, занял бы у меня не менее недели. Сверху головы мои основные жалобы:
- Нет понятия единицы работы. Если я проверю десять измененных файлов, чтобы исправить ошибку или добавить функцию, я не смогу снова просмотреть эти изменения как группу. Даже если они имеют одинаковую проверку в комментариях.
- Динамические представления иногда исчезают при перезагрузке. Если не вдаваться в подробности, это означает, что файлы, на которые могут опираться другие приложения, с вероятностью менее 50% будут оставаться там при перезагрузке компьютера.
- Если я проверю код в своей ветке, а затем вернусь к основному, он не будет автоматически возвращен к основному с тем же комментарием. Это означает, что если я хочу хорошо прокомментированные проверки на основной ветке, я постоянно повторяюсь.
- Практически нет интеграции с Visual Studio (очевидно, это лучше в 7.1, но, конечно, мы еще не обновились)
- Довольно быстрое и бесполезное представление о согласованности пользовательского интерфейса с некоторыми диалоговыми окнами, имеющими кнопки внизу справа, а некоторые - внизу. Также некоторые окна, которые действительно должны быть изменяемого размера (содержат длинные имена файлов), не являются.
- Редко (но достаточно часто, чтобы это произошло хотя бы раз с каждым, с кем я общался в обеих компаниях), ClearCase решит добавить случайный символ в середину файлов XML.
- Дело в том, что IBM меняет за эту лицензию 4600 долларов, и люди платят за это.
Буквально десятки других штуковин отнимают у меня мою продуктивность, так как мне приходится бороться с инструментом, и есть большая вероятность, что я вернусь и отредактирую этот пост, чтобы выразить свое ежедневное разочарование этим.
Размеры Серены были очень резкими. Мы перезагружали сервер каждый день, а также по мере необходимости. В противном случае это становится очень медленным. Я не уверен, является ли это проблемой реализации или проблемой продукта. Также вы можете обратиться к блогу Эрика Синка за более подробной информацией об управлении версиями.
Я могу подтвердить большинство упомянутых здесь материалов о VSS.
Я был вынужден использовать это.:-(
Subversion. Его поддержка ветвления ужасна - вот почему я предпочитаю Mercurial в наши дни; Я не разрабатываю вещи на самолете, но мне нужно разветвляться.
Некоторое время назад я застрял с Serena Version Manager. Это было ужасно. Наш репозиторий был довольно сложным, и количество групп по продвижению, которые у нас были, и филиалов, которые у нас были, и тегов, которые мы имели, было настолько неконтролируемым, что, если вы точно не знали, что вам нужно делать, удачи Гораздо сложнее, чем когда-либо.
Сейчас мы используем TFS (а дома я использую Subversion), и я счастливый разработчик.
Subversion: сервер очень надежный, но нет клиента администратора с графическим интерфейсом (правка: действительно должен быть один с опцией поддержки)
Мы перешли с SourceUn safe на Seapine SurroundSCM около года назад; мы решительно относились к Subversion, но наш администратор репозитория, который делает очень хорошую работу, не является экспертом по командной строке, и без клиента администратора с GUI была огромная дыра в том, как мы могли поддерживать репозитории контроля версий нашей компании.
FWIW, я думаю, что все СКМ имеют проблемы с терминологией. Это делает адское переключение программного обеспечения еще более адским, когда многие пользователи нашей компании не являются программистами с идеальными воспоминаниями. VSS называет каталоги "проектами". Seapine SurroundSCM называет каталоги "хранилищами". (У Subversion были и назойливые названия вещей, но я не могу вспомнить, кто они сейчас)
У Subversion есть два основных недостатка.
- Рабочая копия в 2 раза больше реального размера вашего программного обеспечения. При работе с большими медиа-файлами и несколькими ветками это может быть громоздким.
- Пометка и разветвление - просто копии ствола. Это очень раздражает при отображении структуры каталогов репозитория в рабочие пространства разработчика. Я стремлюсь к традиционным концепциям ветвления и тегирования.
В целом, это очень респектабельный VCS по сравнению со многими альтернативами.
Вот мой личный список. Я не утверждаю, что эти пункты невероятно хорошо изучены, но это основные недостатки, которые я имел с ними, основываясь на моих моделях использования.
- Monotone: необходимость указывать "." обозначать текущий рабочий каталог (в противном случае любая команда применяется ко всей рабочей копии).
- CVS: слишком много, чтобы перечислить. Избегайте любой ценой. (вероятно, обработка разрешений, хотя).
- Subversion: не распространяется.
- SVK: добавление дистрибутива в Subversion кажется неуклюжим.
- Mercurial: это монотонный клон - почему, дорогой бог, почему?
- Базар: действительно странный подход к работе в сети (хотя это может быть устаревшим).
- Git: Качество исходного кода, но это меняется.
Хотя SCM, вероятно, одна из лучших вещей, которую вы можете использовать в среде разработки, меня это всегда беспокоит (а это может быть придирчивостью):
- Когда кто-то еще изменяет мой файл, я не знаю об этом, пока я не фиксирую или не обновляю информацию.
- Слияние - это боль в заднице.
- Когда другие люди сосут, используя его, это мешает больше, чем помогает.
- Слишком сложно управлять разными ветками, тегами и транками одного и того же приложения.
Это все, что я могу думать сейчас.:)
Subversion (ну, Tortoise SVN; я думаю, что это скорее проблема клиента) иногда запутывается, и мне приходится тратить время на копирование чего-либо в пустую папку, повторное добавление, очистку и т. Д., Чтобы я мог получить его в сделать чистое обновление / коммит, не жалуясь на блокировку файлов.
Subversion довольно медленный, ему не хватает таких функций, как офлайн-фиксация, иногда фиксация завершается неудачно и требует обновления, и если вам нужно использовать нотацию @, чтобы заглянуть в репозиторий, его невозможно использовать.
Базар вполне в порядке, но в основном не поддерживается (по крайней мере, с помощью sourceforge). Кроме того, я предпочитаю Subversion модель ветвления / тегирования.
В настоящее время я - пользователь Mercurial, и мне это очень нравится. Но у него есть один недостаток: если дерево ревизий действительно ветвистое, оно работает медленно. Многое из этого сводится к тому, что выбор дизайна был сделан, и, в частности, тот факт, что изменения всегда записываются относительно последнего зафиксированного изменения (а не родительского изменения). Но я все равно остановлюсь на этом.
Для меня сейчас система контроля версий имеет два непременных условия: (1) концепция наборов изменений, поэтому атомарные изменения остаются атомарными; и (2) простое объединение веток без потери информации. По сути, все DVCS имеют это; большинство других VCS не делают. (Perforce подходит близко, но мне всегда мешает, что слияние ветвей не сохраняет последовательность изменений и комментарии из ветви.)
Но если я буду на собеседовании и потенциальный работодатель скажет мне, что они используют CVS, я уйду из собеседования. (На самом деле, это вопрос, который я обычно задаю на уровне телефонных интервью. Вы можете многое рассказать о компании, какой системой контроля версий они пользуются.)
По моему опыту Serena Dimensions каждый плагин ломается. Даже интеграция оболочки Windows Explorer, которая замедляет доступ к сетевым ресурсам для сканирования. Тогда это не говорит вам все, что вы хотите знать об изменениях в любом случае. Изменили файл в нижней части дерева каталогов? Наложение папок более высокого уровня не скажет вам. По сравнению с черепахой SVN это пример отсутствия юзабилити.
Но что мне действительно не нравится в этом, так это то, что когда я делаю Deliver, он обнаруживает изменения файла, а затем, когда я делаю сравнение для просмотра различий, он говорит мне, что Ancestor и Derivative идентичны. Если я не могу доверять встроенному инструменту сравнения, сколько раз он решал, что Ancestor и Derivative одинаковы, когда они на самом деле различаются?
То, как кто-то может создать инструмент управления изменениями, когда базовые принципы управления версиями не работают, мне не под силу. Да, и есть одна ошибка в передаче параметров, если вы попытаетесь интегрироваться с сторонними diff-инструментами.