This information is helpful for many reasons. Perhaps you run a build of your project and get some compile errors in files you haven't touched recently. Perhaps those files are simply out of date because another user has changed them. You can quickly see which files have changed in your workspace and evaluate which you may (or may not) need to resynchronize to get a successful build. Locking a file (which will show in other users' workspaces) informs developers that they may wish to wait to make changes to a specific file.

There are also different locking styles that SCM vendors use. One of these models is optimistic locking. You can get any file at any time and conflicts are resolved on check-in by performing merges. Optimistic models require what is known as "conflict resolution."

The contrast to this is pessimistic locking, which means that once a file is locked by a user, all other users are made aware ahead of time that if they make a change to that file they will need to do a merge later. A pessimistic model is often referred to as a "conflict avoidance" approach. Some SCM tools allow you to see what you have locked, as well as what files are currently locked by other users. This allows the user to decide whether to perform a merge once changes have been made, or to just wait until the file is checked in by the previous user and then make changes (see Figure 2).

 

Team Project Sets
The Import item under the File menu houses many different ways to get files, folders, and projects into the workspace. One of the options is to import a Team Project Set. What this command allows you to do is to import an entire workspace at one time. So if you have a complicated application structure with many related projects, you can import all of them at once! This is an extremely powerful feature that can be used to replicate workspaces on any computer in a single step.

The way this works is your team lead sets up his or her workspace and all of the project relationships, classpath, compile options, and other WebSphere Studio-specific project information. Then they create a Team Project Set file (.psf extension) from the File menu by choosing Export. This file is really just XML-formatted instructions that tell the application how to re-create the workspace. Don't worry if you don't see everything in there that you think it should have. This information is cryptic and meant to be read by the application and not by the user. All of the project metadata and relationship information is kept in the .project file that WebSphere Studio creates for each project. When the workspace is populated during an import, all of that information is still there because the .project file is archived.

Preferences Are Your Friends
There is also a section labeled Team in the main WebSphere Studio preferences panel. Here you can find some generic preferences that can affect how SCM plug-ins behave, as well as specific team provider preferences. Many SCM vendors allow you to tell the backing repository how to store files. The two most common options are as text files and as binary files. The File Content preference page allows you to specify which of the two options you would like to use based on file extension.

Another vendor-generic page is the Ignored Resources page. This page allows you to use regular expressions to specify files or directories that you would like the SCM system to ignore completely. Common things to specify here are bin directories and test file extensions (.bak, for example). This can be an incredibly useful tool when performing large operations.

Some of the vendor-specific information that may also be here includes things such as connection and server information, and behavior specifics. You may choose to have every action in the workspace echoed directly in the repository, for example.

Conclusion
SCM plug-ins allow developers to access everything they require - from a source standpoint - from within a single interface. The aforementioned features highlight some of the principal ways that these plug-ins assist users with their daily development activities. Enterprises are looking more and more for interconnected solutions to standardize on across an organization, and the WebSphere Studio architecture has allowed for tight integrations to seamlessly incorporate applications.

Resources

Tips for Developers Using an SCM Tool
1.  Check in changes often to preserve a development history. This also allows others to integrate your changes.

2.  Integrate early and often. Incorporate others' changes to stay current.

3.  Mark milestones (checkpoint) via your SCM tool. This also allows you to roll back to a stable state in the future, if needed. Milestones also provide a basis for branching and parallel development.

4.  Use SCM to implement process-driven change management. Other things to consider are notifications, integrations, and administration with tools and defect-tracking systems.