Plastic SCM User’s Guide
Table of Contents
1.2. Problems without version control
3.5.1. Modified items in the workspace
3.5.2. Items marked as .unloaded
3.6.1. Internal Checkout details
3.7. Displaying pending checkins
3.9. Revert to a previous revision
3.11. Editing branch properties
3.12.3. Merges from the same branch
3.12.4. Merging from different branches
3.12.5. Merging from a branch and a label
3.12.7. Merging from a changeset
3.12.8. Merging from a revision
3.12.9. Merging from the command line
3.12.10. Cherry Picking or selective merge
3.12.11. Merging an interval of changes
3.13. Subtractive merge (desintegration)
Subtracting a revision interval
3.19. Editing an attribute value
3.20. Deleting an attribute application
3.21. Querying objects with attributes
4.3. Performing a first code import
4.5. Checking out items to work with them
4.6. Finding checked out files
5. Workspace selectors in depth
5.4. The norecursive path rule option
5.5. Specifying wildcards on the path selection rule
5.6. Retrieving an item’s specific revision
6.5. Repository specifications
6.7. Repository server specifications
6.8. Workspace server specifications
7.4. Modifying the workspace selector
7.10. The merge tool for text files
8. Managing projects with Plastic SCM
8.1. Working on the main branch
9.1. Adding projects to the source control system
9.2. Opening existing projects under source control
9.4. Additional source control operations
10.1. Adding projects to the source control system
11.1. Adding projects to the source control system
11.2. Opening existing projects under source control
13. Advanced Query System (AQS)
i. Microsoft Visual SourceSafe
Figures
Figure 1: Plastic SCM components and structure
Figure 2: Types of objects a repository can hold
Figure 3: Sample items and private items
Figure 4: Relation between revisions and items
Figure 6: Representation of the item history
Figure 7: Item revisions contained in a branch
Figure 8: Branch representation
Figure 9: Branch inheritance representation
Figure 10: How the workspace maps branch’s revisions
Figure 11: version tree in the repository structure
Figure 12: hello.cpp item calculated by Plastic SCM
Figure 13: Sample version tree
Figure 14: Sample Branch Explorer
Figure 15. Smart branches define dynamic branch hierarchies
Figure 16: How revisions map to a workspace
Figure 17: Each developer can have many workspaces
Figure 18: Labels applied to revisions
Figure 19: base version control operations
Figure 20: Repository creation dialog
Figure 21: Creating a new workspace
Figure 22: Items added from visual studio
Figure 23: Add to source control from Visual Studio
Figure 24: Elements protected under Visual Studio
Figure 25: Eclipse share project option
Figure 26: Add to source control from Eclipse
Figure 27: Eclipse check in recursively functionality
Figure 28: Checked out elements before update
Figure 29: Check out protection
Figure 32: Checked-out tick detail in Visual Studio
Figure 33: checkout dialog in Visual Studio
Figure 34: A revision is created in the checkout operation
Figure 35: Pending checkouts view in the GUI tool
Figure 36: View pending checkins in Visual Studio
Figure 37: Undo checkout from the GUI tool
Figure 40: Creating a child branch in the GUI tool
Figure 41. Smart branch creation dialog
Figure 42. Editing smart branch properties
Figure 43. How smart branches evolve through time
Figure 44. Two smart branches hierarchy samples
Figure 45: List of items to be merged
Figure 46: Revisions included on a merge operation
Figure 47: Merge from the same branch
Figure 48: Basic merge, merge completed
Figure 49: parallel development scenario
Figure 50: Developers work on the item
Figure 51: Both branches have been integrated
Figure 52: Labeled revisions on the branch have been merged
Figure 55. Subtractive merge, initial code
Figure 56. Subtractive merge, first modification
Figure 57. Subtractive merge, second modification
Figure 58. Subtractive merge, version tree after merging the first change
Figure 59. Subtractive merge, file after the two changes
Figure 60. Substractive revision merge from the GUI
Figure 61. Subtractive merge showing the result of the file
Figure 62. How subtractive merge works
Figure 63. Version tree after a subtractive merge showing the subtractive link
Figure 64. Subtractive merge of an interval
Figure 65. Subtractive merge from GUI
Figure 66: Creating a new label
Figure 67: Apply label to workspace content
Figure 68: Create new attribute
Figure 69: How to apply an attribute
Figure 70: Apply attribute dialog
Figure 71: Edit the attribute value
Figure 72: Delete the attribute application
Figure 73: Query objects with attributes
Figure 75: Creating a workspace
Figure 76: Add solution to source control
Figure 78: Share project to Plastic SCM
Figure 80: Check in recursively
Figure 82: Checked out items in Visual Studio
Figure 83: Check out dialog in Visual Studio 2005
Figure 84: Checked out revision list
Figure 85: Default selector appearance
Figure 86: Selector definition
Figure 87: Sample directory structure
Figure 88. Smart branch scenario to study selector
Figure 89: Workspace selection dialog
Figure 91: Workspace selection
Figure 92: Workspace information area
Figure 93: Change selector dialog
Figure 94. Item menu on items view
Figure 96: Directory diff showing an added directory
Figure 97: Source code diff with syntax highlight
Figure 98: The image diff showing differences side by side
Figure 99: The image diff tool showing blended images
Figure 101: Merge tool file selection dialog
Figure 102: Merge tool showing differences between two files
Figure 105: All changes on the main branch
Figure 106: Branch per developer pattern
Figure 107: Branch per task pattern
Figure 108: Adding to the version control from Visual Studio
Figure 109: Change source control from Visual Studio
Figure 111: Operations on a checked in file
Figure 112: Operations on a checked out file
Figure 113: Additional SCM operations in Visual Studio
Figure 114: Change source control
Figure 115: Checked out without connection
Figure 116: Protection when regaining connection
Figure 117: Select Plastic SCM as version system
Figure 118: Plastic SCM location
Figure 121: Plastic SCM operations from JDeveloper
Figure 122: Error when changing without checking out
Figure 123: Share project option
Figure 124: Choosing your version control: Plastic SCM
Figure 125: Plastic SCM settings
Figure 126: Adding items to Plastic SCM
Figure 128: Check in recursively
Figure 129: Eclipse plug in operations
Figure 130: Plastic SCM toolbar in Eclipse
Figure 131: Plastic SCM preferences
Figure 132: Plastic SCM decorators in Eclipse
Figure 133: Query language grammar
A Brief Introduction to Software Configuration Management
A Software configuration management solution often contains the following components:
Having all of those pieces doesn’t mean that you have an effective SCM solution, however. To have an effective (as opposed to complete) SCM solution you need to understand that there are many ways that one can have implement the set of items in the list, and the right way will be different for every organization. You also need to know that these items are focused on the macro level; for your SCM process to work the micro process: what happens each day in the developer’s workspace needs to be correct. It is also necessary to remember that the reason we have SCM processes and tools is communication and teamwork.
To create an appropriate and effective SCM process you need to understand that the SCM process works together with your architecture and organizational structure (and culture). An SCM process that works well for a 3-person startup building web applications will not work for a larger application development process distributed across countries. What these two types of organizations will share is that the process is simple to use and allows for repeatability. This is where good use of patterns comes in.
Some of the key things that your SCM process should allow for, but which you won’t often see on a list are the ability for developers to create a Private Workspace that contains the version of the application that they need to work with; the ability for developers to build the application before integrating with the rest of the team, and testing to verify that everyone is meeting each other’s expectations.
The theme that underlies all effective SCM processes is that SCM is there to facilitate communication. A good SCM toll will help your team work together.
Stephen P. Berczuk
October 2006
About this guide
This guide describes Plastic SCM’s regular use. It will introduce the features and techniques used to get the most out of the tool.
This guide is targeted to the average developer, assuming familiarity with operating system concepts, programming languages and integrated development environments (IDEs) like Microsoft Visual Studio or Eclipse.
Online documentation
Besides this and the rest of the guides, Plastic SCM provides online reference throughout its different client frontends.
On the command line interface, both Windows and Linux, this reference can be obtained with the command:
cm help
For extended information on a specific command, type:
cm help command
The graphical interface provides online reference through the Help menu.
Documentation errors
If you find any problem in this guide or any other part of the online reference, please notify it using the following email address:
Plastic SCM is a complete Software Configuration Management (SCM) platform, able to manage the evolution in time of source code and any development asset. It improves visibility and parallel development, ensuring optimum collaboration among teams and introducing new visualization formulas on a user-friendly interface.
Development groups not using SCM are most likely familiar with the following topics: