Разница между Subversion и MKS

Question

Пожалуйста, дайте мне знать различия между Subversion и MKS.

Answer 1

Subversion: централизованная VCS, семантика слияния или блокировки, основанная на репозитории, с открытым исходным кодом, огромная доля рынка (хотя она теряет некоторые позиции для записей DVCS, таких как Mercurial и Git), бесплатно, отлично набор инструментов и вспомогательная инфраструктура.

MKS: централизованная VCS, только семантика блокировки, на основе репозитория, с закрытым исходным кодом, относительно ограниченная доля рынка, не бесплатная ($ 999 + / лицензия), значительно менее развитый набор инструментов.

Answer 2

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

MKS удалось полностью запустить интеграцию Eclipse / WSAD (SVN / CVS интегрируется безупречно).

MKS - самая большая куча дерьма, которую я когда-либо использовал для SCM (и это говорит о многом, так как я также использовал Microsoft Visual Source Safe на ранних этапах).

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

Это зависит только от вас. Если вы хотите порадовать руководство и выберите " право " Выбор, который помечает все коробки, иди с МКС. Если вы хотите, чтобы ваши разработчики действительно выполнили некоторую работу, тогда используйте SVN до конца.

Но, поскольку мне пришлось использовать MKS, я добавлю более ранний постер на CruiseControl for CI, который работает, но немного устарел.

Answer 3

Как упомянул Дойл, самая большая разница между MKS и SVN заключается в том, что SVN — это специализированная система контроля версий, тогда как MKS — это целый набор приложений, охватывающий весь жизненный цикл: от управления требованиями и отслеживания ошибок до управления тестированием.И, кстати, он также включает в себя контроль версий.

Некоторые конкретные проблемы, с которыми я столкнулся, перечислены ниже.Имейте в виду, что это было по состоянию на 2008 год, поэтому я не знаю, сохраняется ли это в более новых версиях:

• Медленный (применяется в основном для крупных проектов;для маленьких не так уж и плохо)
• Проблемы с поиском сторонних инструментов для интеграции с ним.
• Инструменты, которые утверждали, что интегрируются с ним, имели ненадежную интеграцию (в частности, Visual Studio и Code Collaborator).
• Стратегия ветвления сбивала с толку;получил много пустых взглядов, пытаясь объяснить пути разработки и общие подпроекты
• Слияние между ветками было неуклюжим и хлопотным.
• Трекеру ошибок не хватает гибкости рабочего процесса по сравнению с другими инструментами для отслеживания ошибок.
• Инструменты администратора были недостаточно отточены

я не сделал ненавидеть это, но я не могу рекомендовать это.