[1 ]   
Once you have succeeded in using Visual SourceSafe with the Visual FoxPro Project Manager, there are a number of ways in which the collaboration between the two products can be enhanced:
Rather than using the internal source code control mechanism, it is possible to control Visual Studio using Automation directly from FoxPro. You can scan the contents of a project (PJX files are just data tables) and process directly against the SourceSafe backend.
Whenever a SourceSafe operation is attempted, an "In Desktop" window appears, blocking your access to the FoxPro application and occasionally intercepting keystrokes. Thanks to Christof Lange for pointing out that you can get rid of this annoying window with HIDE WINDOW "SOURCE" or HIDE WINDOW "Ergebnisse der Quellcode-Kontrolle."
Attempting to add a program that is not within the subdirectory tree of the main project results in a SourceSafe Error. SourceSafe will not allow you to include files outside of project directory tree. There are several work-arounds, depending on the situation. If the file is used in this application only, the simplest thing to do is just to move it into the directory structure. If the file is used in multiple projects, one alternative is to add it to its own project, within the SourceSafe native interface, and then use sharing within VSS, add the file to the current project, within FoxPro add it to the project, and select "overwrite" to update the file to the most recent version within FoxPro.
Look at sharing between projects to maintain control of common files (FoxTools, framework source code); considering "pinning" to lock in versions for shared branches.
Look at labeling options within Visual SourceSafe to control and document versions sent to testing or released to clients.
The October '97 issue of FoxPro Advisor has an excellent article by Mark Wilden with several suggestions on changes to SCCTEXT.PRG. One issue he identified was a problem with SCX and VCX files jumbling the order of methods each time they were saved. When SCCTEXT generated the method code for the corresponding SCA or VCA file, the methods were not sorted, so viewing differences in the files was difficult. Mark proposed a simple change to the SCCTEXT program to sort these methods before writing out the file.
The Project/Source Control/Share… option allows you to add any controlled files from any other project directly into your project. Unfortunately, there is no option to specify where these files are stored - all are placed in the project root directory. Move the file within the SourceSafe interface by dragging and dropping in to the correct folder and deleting the file from the root (Yes, this is how you have to do a "move" - copy and delete - there is no native move functionality). Finally, modify the PJM file directly to point to the new location of the file.
By default, the VFP-VSS interface does not include data files under source code control, nor does it include the database container. Consider adding data files that are more control files than end-user data. Take a look at the GENDBC program, included with Visual FoxPro in the TOOLS\GenDBC directory, to generate a program containing all of your database container properties and methods. Consider a tool like xCase or Stonefield Data Toolkit to generate the design meta-data for preservation within SourceSafe.
Under some circumstances, projects under source code control perform unacceptably slowly. Ensure you are using the latest version of FoxPro - 5.0a had major speed improvements over 5.0. Ensure your network is performing correctly. Use the SourceSafe admin looks like ANALYZE.EXE to test and correct problems with the SourceSafe data store.
There is no native support for remote access, and Visual SourceSafe over RAS can be unacceptably slow on slower dial-up lines. Consider alternatives such as using a shadow directory structure to allow developers to "get" all current source code without invoking VSS, using an store-and-forward process, like e-mail, to transfer files to and from remote users, or setting up an Automation server locally with a better remote interface.
Microsoft has provided us with hooks into the project manager and source code control to allow us to reliably maintain source code shared among multiple developers. A little time spent understanding how the mechanism works and how it can be used to best advantage can pay off for the multi-developer team.
How many errors are typical of your development projects? Is there a member of your team who excels at I/O routines? How strong are your programmers at isolating and identifying bugs?
Most of us are unable to answer these questions authoritatively. We probably have a good grasp of generally how the team is doing, but it seems like no one is keeping score. This is where anomaly-tracking systems can come into play. An anomaly tracking system can help you understand where your team's strengths and weaknesses are, and help identify areas where you want your team to put more effort or care, or perhaps identifying areas where your team could use additional help. Check out products like Microsoft ATS, Visual Intercept, Track, and PVCS-Tracker for some ideas in doing this. Microsoft's Anomaly Tracking System will be demonstrated.
No discussion of development issues would be complete without some discussion of the Software Engineering Institute and the Capability Maturity Model (CMM) of software development. The Software Engineering Institute is a government-sponsored project at Carnegie Mellon University with a mission "to provide leadership in advancing the state of the practice of software engineering to improve the quality of systems that depend on software." CMM describes levels of achievement for a software development enterprise, with a focus on predicting the future achievements of the organization. One observation can be derived from the information provided: Tools are not the solution to the problem. Tools are a means to solve problems. Maturity in software development, similarly to life, can only be achieved as a gradual set of steps.
The CMM model presents a set of "levels of maturity," and, like their equivalence in real life - infancy, childhood, adolescence, adulthood, middle age and seniority - these are likely to be stages to grow through. The levels are described briefly in the table attached, but anything short of a book does not do the CMM justice. Check out writings by Watts Humphrey and the SEI (some of which are in the bibliography) for much more information on this important model.
|Level 1 a.k.a. Level 0||Initial, a.k.a. "Chaos"||The success of any one project is no indicator of future successes.|
|Level 2||Repeatable Process||The beginning stages of repeatable success: project plans, estimates, and concurrence from all parties, coordination and responsibility for fulfillment of estimates.|
|Level 3||Defined Process||Oversight and review of procedures with an aim at creating a defined process which encompasses all tasks, development of project risk plans, SCM controls, a standard process framework.|
|Level 4||Managed Process||Process management and analyses provide constant feedback and refinement of all phases of the development process, yielding corresponding product quality improvements.|
|Level 5||Optimizing Process||Productivity improvements are aimed primarily at the process itself.|
Table 1: The Five Levels of the Capability Maturity Model
Unless you are a member of a rare organization, I would like to welcome you to level one. But like many 12-step programs, the first crucial step is the recognition that there is a problem. In this case, organizations that are aware of the SEI and CMM are almost always better than those who are not, even if the progress at the former companies is slow in coming.
Since tools are not the solution, how does an organization advance? Well, paradoxically, part of the answer is that advancement comes though the use of these tools. It is not the tool-usage that causes the advancement, however. Rather, it is the organization recognizing the need for the procedures that require these tools, and using the documents produced by these tools to better the development process, that causes advancement.
Too many organizations fall prey to the idea that these tools are the solution to their development dilemmas. Often referred to as the "Silver Bullet Syndrome," projects which make wildly optimistic estimates based on the imagined time-savings of a new promising tool are almost always doomed to failure. While a new tool may provide some time savings, the tool is far more likely to require extensive training, a few patches and a minor upgrade or two. The true value of the new tool is more often improved quality than reduced costs, and that on the second or third usage more often than the first.
While tools are not the answer, we can use tools to begin to document the process we hope to understand, standardize, measure and optimize. The remainder of this document will briefly examine the categories of some of these tools, and give you some insight into their usefulness.
[1 ]