More Proof that ClearCase Is A Toy – Not For Production Use

Yet more reasons to avoid ClearCase….

Scenario – I checked out a bunch of files on Friday, worked them for a few days adding all sorts of yummy goodness.  After code reviews I start checking things in.

One file has been updated by somebody else – no problemo – happens all the time on a large project with many programmers.  But wait – who is this “Reed Shilts” guy – somebody with MY name has checked in a new version of the file I have been editing ?
Looking through the CC history, nope – no new version has been checked in by Reed…

Since nobody here trusts the “Merge” capability in ClearCase (it sometimes works…) – I un-check out the file, re-merge my changes, then check it in.

Remote Debug the Server Side ResultSetFilters and ResultCheckers

Somebody on the internal newsgroup asked how to use the Eclipse remote debug capability to debug custom ResultSetFilters and ResultCheckers – that are running on the SUP server itself.

Somebody internally beat me to the punch, but it is described in:
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.sup.doc-SUP-1.0.1/projects/sup/tooling/en/source/t_mbo_writing_result_set_filter.html

Like I said, this is basically using standard Eclipse remote debugging, after the Unwired Server has been restarted in JPDA (Java Platform Debugger Architecture) mode.  You can set breakpoints and party in the code (using the brain-damaged Java debugger, but better than System.out.println()….).

(Update 19-July-2012)
On the internal newsgroup, one of the server people posted this helping bit:

You should be able to debug your filter running within Workspace by adding the same debugging JVM flags (all one line):

-Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

to UnwiredWorkspace.bat.

I believe you might need to use a different instance of Eclipse to run the debugger. I’ve seen some pretty strange behavior using the Eclipse debugger to attach to itself.