David White's Source Safe Addin For JBuilder

If JBuilder hangs, it is likely due to a failure to accurately supply a Source Safe user name (and password). The addin uses the Source Safe command line interface (SS.EXE) to get much of its work done. If you encounter a hang, you should see an SS.EXE process in the Windows NT Task Manager (not sure where to look on Win 9x).

What is typically happening is that SS.EXE prompts for user name and password if required but not supplied as command line arguments. Because the addin runs SS.EXE in the background to "hide" its details from the user, you do not see and cannot respond to its prompts for user and password.

Make sure that you have provided accurate values in the addin's properties file. One easy way to test is to run the SS.EXE program yourself (try "SS.EXE status") and answer its prompts with the values you intend to use. SS.EXE should be located in the \Win32 sub directory beneath the location specified for the SourceSafePath addin property.

Sometimes you are supplying the correct values but the addin is not "talking" to the correct Source Safe database so the values are correct but in the wrong context. See the discussion below about use of the SSDIR environment variable to ensure that SS.EXE is pointed at the correct database.

A good initial step is to open a DOS box and restart JBuilder using "JBuilder.exe -verbose" and checking the console output from the addin. JBuilder.exe is located in the \bin sub directory under the JBuilder installation directory.

This typically occurs because the addin fails to initialize properly. Usually, this is due to a failure to find the SS.EXE program at the correct location relative to the directory specified in the addin's SourceSafePath property. SS.EXE should be found in the \Win32 sub directory beneath the location specified for the SourceSafePath addin property.

There is likely a better way to generate the dialog and to handle the mapping of JBuilder projects to Source Safe projects. This is under consideration for a later release. For now, recognize that the dialog is only "built" once per JBuilder session. So it is slow only the first time it is displayed. Subsequent requests for the dialog are almost immediate.
In many cases setting the addin's InitialProject property is all that is needed. My experience is that most java
projects have lots of packages but these are typically located under a single "super" package like "com.comapnyname.product". In VSS, the project/sub project tree typically exactly matches the package name
tree. So I choose the Source Safe project for the topmost level of the package tree and leave it there. The addin and VSS does the rest. It is a bit trickier for adds and that is where the InferProjectNameOnAdd addin property comes into play.
This is mostly intentional but partly not enough time. The idea was to provide light-weight and easy access to the most commonly used features of the source control system from within the JBuilder IDE. It is not my intention to replicate the Source Safe Explorer inside of JBuilder. I do provide easy access to the Explorer from within JBuilder so you can perform other (more administrative) functions like creating projects, setting working dirs, etc. I have had several requests for this functionality and have looked into providing it on several occasions. First, since the addin uses the command line interface (SS.EXE) to get version control info, this would add many more invocations of the program to get and maintain the checkout status. I feel that this is not a good use of computer time and may make JBuilder appear even slower than it already is.

Without constant use of SS.EXE to get at the "real" checkout status, the best that can be done is to "estimate" checkout status by mapping it to the file's read-only flag. JBuilder already does this but only when the file is actually open in an editor window. You cannot see this in the project view. I have already suggested this to Borland, you should too. Display of read-only status is really the IDE's job. Also, the case can be made that read-only status does NOT map to checkout status. Come on now, who among us has not flipped the read-only bit to work on a file prior to checking it out of the source control system?

The hang occurs because the SS.EXE program is asking for input to which you are not allowed to respond. This is similar to what happens with prompting for user ids and passwords (see above). Basically, multiple checkouts are not supported. My experience is that most Source Safe installations do not use this feature and it proves to be a pain to support since there is no easy way, via the command line interface to Source Safe, to know if multiple checkouts are enabled. So I just avoided the whole issue. You can use multiple checkouts and all is fine unless there is the need to merge. Sorry!