3

Please let me know the differences between the Subversion and MKS

Afriza N. Arief
  • 7,696
  • 5
  • 47
  • 74

3 Answers3

22

Subversion: centralized VCS, merge or lock semantics, repository-based, open source, massive market share (though it's been losing some ground to the DVCS entries like Mercurial and Git), free, excellent toolset and supporting infrastructure.

MKS: centralized VCS, lock semantics only, repository-based, closed source, relatively limited market share, not free ($999+/license), significantly less well-developed toolset.

John Feminella
  • 303,634
  • 46
  • 339
  • 357
  • 2
    Updating this answer, since I've had the (mis?)fortune to do some work on a few projects for clients that are using MKS. In addition to everything above, MKS does provide a command-line interface similar to Subversion's, although much more limited in power and efficiency. Also, to be fair, MKS as a suite is more than a just version-control tool -- it also provides issue tracking and other related services. This answer is only in the context of MKS Integrity, the main source-control product. – John Feminella Feb 08 '10 at 16:43
  • Another pain point is that it's very difficult to find other tools that integrate well with MKS. The only real contender on the market for a CI tool that will integrate with MKS is Anthill Pro, and they're not free either. There are rumors that Hudson is going to have some MKS integration soon. – John Feminella Feb 08 '10 at 16:44
  • If I understand what you mean by "merge" and "lock" semantics, as of 2011, MKS provided both. At my client, the installation was set for what I think you mean as "lock" semantics by default, but if you chose to checkout with what MKS calls "non-exclusive" locks, you could checkout and edit at will, but will be prompted to merge if someone has checked in changes since you originally checked out the file. – Michael Lang Dec 14 '13 at 02:51
  • As of 2011 that was true. This answer was written in 2009 though. :) – John Feminella Dec 14 '13 at 16:15
  • Yep, I'm just updating for the benefit of anyone else stuck with MKS. Our team's productivity got a huge boost when we discovered the non-exclusive locks feature. I've moved on from that client, but still vicariously feel the pain of anyone stuck having to wrestle with MKS :) – Michael Lang Dec 16 '13 at 07:20
  • Sorry for Necroposting - had to comment. The organization I just joined uses MKS Integrity as version control - It is just horrible. I can not believe how bad it is, lol. I am coming up with a presentation as to why we should switch to Git and found this post. I will use some points listed here so thank you :) – Chuck Apr 05 '18 at 22:53
10

If you need Forrester to tell you what the best SCM is, then you're already in trouble. Any idiot "analyst" can put together a fantastic report on the amazing management functions MKS provides, but ask a developer worth his/her salt who has ever had to use MKS would never recommend it.

MKS managed to completely botch the Eclipse/WSAD integration (SVN/CVS integrates flawlessly).

MKS is the biggest steaming pile of crap I've ever used for SCM (and that's saying a lot as I've also used Microsoft Visual Source Safe in its early days).

Yes, Subversion is not "free" to support, but anybody can set it up and any sysadmin with half a brain could administer it and do appropriate backups.

It's up to you though. If you want to please management and pick the "right" choice that ticks all the boxes, go with MKS. If you want your developers to actually get some work done, then go with SVN all the way.

But, having had to use MKS, I'll second the earlier poster on CruiseControl for CI which does work, but it's a bit dated.

Justin
  • 101
  • 1
  • 2
8

As Doyle mentioned, the biggest difference between MKS and SVN is that SVN is a dedicated version control system whereas MKS is a whole suite of applications covering the entire lifecycle, from requirements management & bug tracking to test management. And oh-by-the-way, it includes version control too.

Some specific problems I had with it are listed below. Please bear in mind that this was as of the 2008 timeframe so I don't know if it still holds true in newer versions:

  • Slow (applies mostly for large projects; for smaller ones not so bad)
  • Trouble finding 3rd-party tools to integrate with it
  • The tools that did claim to integrate with it had flakey integrations (specifically Visual Studio and Code Collaborator)
  • Branching strategy was confusing; got a lot of blank looks trying to explain development paths and shared subprojects
  • Merging between branches was awkward and troublesome
  • Bug tracker lacks some workflow flexibility compared to other bug tools
  • Admin tools were less than polished

I didn't hate it, but nor can I recommend it.

Lynn
  • 1,103
  • 15
  • 29