Actually, I would like MKS Source Integrity to be dead, but I still am forced to deal with it.  Instead of being dead, I’ve really just going to lock it up in a tower and, when I really need it, I take it out, use it, and throw it back where it can’t harm anyone.

Because I believe tools should be used to help me, not to waste my time.  Sure, everything has it’s warts, but working around those warts should make things worth using.  And I don’t like to use tools just because that is what everyone is using — I like to use tools that make things better for me and for others.

Everyone I work with is scared of MKS.  No one wants to put themselves in a position where they have to branch, merge, or other things that just happen to be what an SCM system is for. If I go to get a previous revision of a file, I have to commit it (without changing it) to make it the active revision. So I have different revisions of the exact same file in my project.  Insanity!

Every time I need to do a release, I end up fighting MKS over something or other.  I assume it works one way and MKS always stubbornly works in another, and no one here tells me that and no one knows how to fix the problems I get myself into. I always spend at least an afternoon, if not a whole day, dealing with some mess that I got myself into with MKS.

Today am I in Day Two with my latest battle and I have declared that I have had enough.  This war is not worth fighting. If I can’t pass through the valley, then I’ll just go around it, via Subversion.

Here is the game plan:

1. Install a local-only version of Subversion
2. When I finally get a production-ready version of what I’m working on done, import that into my Subversion repository.
3. Work from that Subversion repository only.
4. Branch, merge, and tag to my heart’s desire,
5. When I’m ready to make a release, do a “svn checkout” and import that into MKS as sandbox.
6. Deploy that code and, when it goes well, make my MKS checkpoint and do to it.

There are drawbacks to this approach. Here are some on the stop of my head:

1. Others working will not see my changes in MKS because I’m not working from the same source.  But, for the moment, I’m a lone ranger on this project.
2. Doing the sync between MKS and SVN will be messy.  Yet, it probably won’t take me two days, like what I’m doing now.
3. Obviously, MKS won’t really reflex the reality of the project. But it’s reality is too warped for me.  And, as I said in #1 — it’s good to be lone ranger sometimes.

One Response to “MKS is Dead to Me”

1. Where Are The Wise Men? » Blog Archive » Using Version Control in Emacs says:

   June 20, 2008 at 12:38 pm

   [...] Let’s say you are working on a project that is under some version control system.  You are editing a file and you type “C-x v v”.  Then Emacs will do the next logical thing with that file.  If the file is not on version control, it will be added.  If it is, it will ask for a comment and check-in the file.  Note that no where do you actually tell Emacs which version control you are using.  It knows. I’ve done this successfully with Mercurial and Subversion and apparently their are many more.  I haven’t tried it under MKS, but that’s okay, because I refuse to use it anyway. [...]
2. matthias says:

   July 27, 2009 at 9:23 am

   My team started a collection of funny error messages
   This collection does not worth much since these funny error messages are not rare