views:

1414

answers:

6

A friend of mine works in a small team where the developers (Java and .net), who currently use SVN for their source control, are about to have MKS Integrity forced upon them.

My friend would like to keep an open mind but I suspect that secretly he wants to stay with SVN.

Is there anyone out there who would be willing to share their experience/opinions (good, bad or indifferent) of MKS?

+2  A: 

I use MKS where I work, but I've never used SVN, so I can't give you a comparison, but I can tell you about MKS. I suspect, however, that some of the resistance to switching to MKS is simply because it's a change, and some people don't like to change.

The good:

  • Is pretty easy to use, once you become familiar with the IDE
  • Can be used for bug tracking, environment requests, new development tasks, etc
  • If you're on the newest release, you can have simultaneous locks on files, one exclusive and multiple non-exclusive locks

The bad:

  • The integration with some tools is unreliable at best (e.g. we have not been able to get it working properly with the RAD IDE)
  • If you use LDAP authentication with it, and you leave the application open, when your LDAP password expires, it will use up your grace logins because it continually runs some authentication. (Of course, your password is most likely to expire at midnight, and if you're working for a company, they want you to turn off your computer when you leave, which you do, right?)
Elie
What does a non-exclusive lock do? Is it just a flag that says "hey, I'm working on this so heads up if you're planning on working on it too?"
John Price
Pretty much, but it also lets you essentially "book the file" so that you're the next person to get the exclusive lock.
Elie
+1  A: 

Hi all,

Earlier i have used SVN, and currently using MKS. I have used many features of SVN. Always i feel SVN is better than MKS. I can mention one thing, in MKS there is no way to know "what are all the files have been committed in a specific revision". This is very useful if something goes wrong in development.

+1  A: 

I have been using SVN with small teams quite a bit and have been enjoying it. Recently, I moved to a fortune 500 company that uses MKS. Fortunately, they will soon be switching to SVN (yes!). Its not that MKS has bugs, but it just seems like MKS makes version control seem difficult when it really isn't. Why are there 50 buttons on the GUI when all you need to do is check in/check out on a daily basis. Also, they have all these extra terms you have to learn, like "sandbox", "member", "resynchronize", "working file". You have an idea what they mean, but I found myself checking the help file a lot to make sure I wasn't blowing away any repositories sometimes.

David Ackerman
+1  A: 

At work we are using MKS. I don't like it very much. Compared to other revision control systems the GUI is very confusing when you are new to MKS. The Visual Studio integration still seems to be very "unstable". The only reason why my company is still using MKS is the missing issue tracking integration of other revision control systems (only MKS and TFS have it out of the box).

Personally i do like SVN much more. You are more flexible because there are a lot of front ends and integrations available. And actually you don't have to pay for.

Also a good alternative is Perforce, which is also free for small teams and OpenSource projects.

Alexander
A: 

At work we are forced to run MKS in windows and develop in a Linux environment. We have issues with same name different case files, symbolic links, permissions and devices etc. I wish we could use svn!

dev
A: 

Personally, I like MKS. It appears to be built on rcs so its underpinings are very similar to cvs and svn, and the client is a nice full-featured cross-platform ui, with personalizable context (popup) menus. There is a built-in graphical view of project and member (file) branching and merging. And contrary to one of the earlier comments, as long as you create project 'checkpoints' to snapshot the state of the project (i.e. per build), you can compare two checkpoints and see what files have changed between them, or create a build sandbox of any checkpoint, or create a new "developer branch" for prod support on an old version.

Our technique is to use a "floating" label called "prod" or "test" that we move to the desired checkpoint, so the prod or test environment build script automatically knows which checkpoint to grab. The only problem is that it has to be a complete delete/rebuild process instead of 'update', because the sandboxes are locked to a particular checkpoint version number.

You can run the java-based gui on linux with no problems, but your server (windows or unix) would dictate file name case-sensitivity. I believe you can choose lock-change-unlock or change-merge paradigms per project.

chris