Разница между Subversion и MKS
-
05-07-2019 - |
Вопрос
Пожалуйста, дайте мне знать различия между Subversion и MKS.
Решение
Subversion: централизованная VCS, семантика слияния или блокировки, основанная на репозитории, с открытым исходным кодом, огромная доля рынка (хотя она теряет некоторые позиции для записей DVCS, таких как Mercurial и Git), бесплатно, отлично набор инструментов и вспомогательная инфраструктура.
MKS: централизованная VCS, только семантика блокировки, на основе репозитория, с закрытым исходным кодом, относительно ограниченная доля рынка, не бесплатная ($ 999 + / лицензия), значительно менее развитый набор инструментов.
Другие советы
Если вам нужен Forrester, чтобы сказать вам, что такое лучший SCM, то у вас уже есть проблемы. Любой идиот "аналитик" может составить фантастический отчет об удивительных функциях управления, которые предоставляет MKS, но спросить разработчика, который того стоит, которому когда-либо приходилось использовать MKS, никогда бы не порекомендовал его.
MKS удалось полностью запустить интеграцию Eclipse / WSAD (SVN / CVS интегрируется безупречно).
MKS - самая большая куча дерьма, которую я когда-либо использовал для SCM (и это говорит о многом, так как я также использовал Microsoft Visual Source Safe на ранних этапах).
Да, Subversion не является "бесплатной" чтобы поддержать, но любой может настроить его, и любой системный администратор с половиной мозгов может управлять им и делать соответствующие резервные копии.
Это зависит только от вас. Если вы хотите порадовать руководство и выберите " право " Выбор, который помечает все коробки, иди с МКС. Если вы хотите, чтобы ваши разработчики действительно выполнили некоторую работу, тогда используйте SVN до конца.
Но, поскольку мне пришлось использовать MKS, я добавлю более ранний постер на CruiseControl for CI, который работает, но немного устарел.
Как упомянул Дойл, самая большая разница между MKS и SVN заключается в том, что SVN — это специализированная система контроля версий, тогда как MKS — это целый набор приложений, охватывающий весь жизненный цикл: от управления требованиями и отслеживания ошибок до управления тестированием.И, кстати, он также включает в себя контроль версий.
Некоторые конкретные проблемы, с которыми я столкнулся, перечислены ниже.Имейте в виду, что это было по состоянию на 2008 год, поэтому я не знаю, сохраняется ли это в более новых версиях:
- Медленный (применяется в основном для крупных проектов;для маленьких не так уж и плохо)
- Проблемы с поиском сторонних инструментов для интеграции с ним.
- Инструменты, которые утверждали, что интегрируются с ним, имели ненадежную интеграцию (в частности, Visual Studio и Code Collaborator).
- Стратегия ветвления сбивала с толку;получил много пустых взглядов, пытаясь объяснить пути разработки и общие подпроекты
- Слияние между ветками было неуклюжим и хлопотным.
- Трекеру ошибок не хватает гибкости рабочего процесса по сравнению с другими инструментами для отслеживания ошибок.
- Инструменты администратора были недостаточно отточены
я не сделал ненавидеть это, но я не могу рекомендовать это.