Какова самая раздражающая вещь о системе управления версиями (SCM), Вы используете?

Размеры Серены были очень аварийными. Мы перезагружали сервер каждый день, а также по мере необходимости. В противном случае это становится очень медленным. Я не уверен, является ли это проблемой реализации или проблемой продукта. Также вы можете обратиться к блогу Эрика Синка за более подробной информацией об управлении версиями.

Я могу подтвердить большую часть материала , упомянутого здесь о VSS.

Я был вынужден использовать его. : - (

Некоторое время назад я застрял с Serena Version Manager. Это было ужасно. Наш репозиторий был довольно сложным, и количество групп по продвижению, которые у нас были, и филиалов, которые у нас были, и тегов, которые мы имели, было настолько неконтролируемым, что, если вы точно не знали, что вам нужно делать, удачи. Гораздо сложнее, чем когда-либо.

Сейчас мы используем TFS (а дома я использую Subversion), и я счастливый разработчик.

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

У Subversion есть два основных недостатка.

• Рабочая копия в 2 раза больше действительного размера вашего программного обеспечения. При работе с большими медиа-файлами и несколькими ветвями это может быть громоздким.
• Пометка и ветвление - это просто копии ствола. Это очень раздражает при отображении структуры каталогов репозитория в рабочие пространства разработчика. Я тоскую по традиционным концепциям ветвления и тегирования.

В целом, это очень респектабельная VCS по сравнению со многими альтернативами.

Subversion : сервер очень надежный, но нет клиента администратора GUI ( edit : действительно должен быть один с опцией поддержки)

Мы около года назад переключился с Source Un safe на Seapine SurroundSCM; мы решительно относились к Subversion, но наш администратор репозитория, который делает очень хорошую работу, не является экспертом по командной строке, и без клиента администратора с GUI была огромная дыра в том, как мы могли поддерживать репозитории системы контроля версий нашей компании.

FWIW, я думаю все из СКМ имеют проблемы с терминологией. Это делает адское переключение программного обеспечения еще более адским, когда многие пользователи нашей компании не являются программистами с идеальными воспоминаниями. VSS называет каталоги "проектами". Seapine SurroundSCM называет каталоги «хранилищами» , (У Subversion были и назойливые имена для вещей, но я не могу вспомнить, кто они сейчас)

Subversion (ну, Tortoise SVN; я думаю, что это скорее проблема клиента) иногда путается, и мне приходится тратить время на копирование чего-либо в пустую папку, повторное добавление, очистку и так далее, чтобы я мог заставить его делать чистое обновление / коммит, не жалуясь на блокировку файлов.

Subversion довольно медленный, ему не хватает таких функций, как offline-commit, иногда коммит завершается неудачно и требует обновления, и если вам нужно использовать нотацию @, чтобы заглянуть в репо, использовать его невозможно ,

Базар вполне в порядке, но в основном не поддерживается (по крайней мере, с помощью sourceforge). Кроме того, я предпочитаю модель ветвления / тегирования Subversion.

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

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

Это все, что я могу думать сейчас. :)

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

• Monotone: необходимость указывать "." для обозначения текущего рабочего каталога (в противном случае любая команда применяется ко всей рабочей копии).
• CVS: слишком много, чтобы перечислить. Избегайте любой ценой. (хотя, вероятно, обработка разрешений).
• Subversion: не распространяется.
  • SVK: добавление дистрибутива в Subversion кажется неуклюжим.
• Mercurial: это монотонный клон - почему, дорогой бог, почему?
• Bazaar: действительно странный подход к работе в сети (хотя это может быть устаревшим).
• Git: Качество исходного кода, но оно меняется.

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

Для меня сейчас система контроля версий имеет две функции sine qua non: (1) концепция наборов изменений, поэтому атомарные изменения остаются атомарными; и (2) простое слияние ветвей без потери информации. Практически все DVCS имеют это; большинство других VCS этого не делают. (Perforce подходит близко, но меня всегда беспокоит, что слияние веток не сохраняет последовательность наборов изменений и комментариев из ветки.)

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