Using version control to simply commit, update, and share projects can be very useful, but there is additional functionality that can be helpful in many of your projects.Version control can change the way you work. It can enable a truly team-oriented development methodology.
Version control is a tool for sharing and backing up your project. You should take full advantage of it. That means committing often and updating frequently. You should learn to be comfortable with committing. The project doesn’t need to be perfect, just make sure you won't impede your teammates.
You should also update frequently to get your teammate's changes. This ensures that you are working with an up-to-date project, and your changes can work with the changes your teammates are making. You also resolve conflicts in a better way. The earlier you can resolve a conflict, the easier it is be to resolve that conflict.
For example, if two individuals are editing the same policy and they work separately for a week, the two versions of the policy will be very different. This makes it very likely that there are conflicts and very likely that those conflicts are difficult to resolve. If those two users update frequently, they can avoid most of the conflicts and make them much easier to resolve.
Whenever you commit a change to the version control server, you are prompted for a comment. Comments are your chance to describe the change for yourself and for your teammates. Comments can explain why you did something and what you were thinking when you did it.
Good comments should take the form of sentences. They should describe what you did and why you did it. A well-written comment should give you a good idea of what has changed, but it does not need to describe every change in detail.
Created a new project for work on the new Active Directory drivers for Unilateral Widgets Incorporated.
Added a new AD driver to connect to the second directory and moved policy1 to a library so we can access it from the new driver.
Changed the second rule in policy1 to avoid the potential for an infinite loop when handling more than three users.
Comments should not be too brief:
Added new policy
New project
Undid Joe’s change
Comments should also not be too specific:
Changed the condition of policy add password rule operation-data to be the following: <and> <if-operation op="equal">add</if-operation> <if-password op="available"/> <if-xpath op="not-true">operation-data</if-xpath> </and>
A tag is a readable name given to a specific revision. For example, you could tag revision 100 as Release 1.0. Tagging is most useful for identifying significant revisions. If you certify that you are ready to send a project to a customer, that is probably a good time to create a tag. You can then access that tag later if you need to roll back a change. The combination of tagging and the Get from History feature gives you a powerful tool to manage releases and deployments.
You can use Subversion keyword substitution to give you more information on selected objects. For example, you can use the Description area to track the revision number, the date and time an object was last submitted to Subversion, and who submitted the last revision in the description of an object. The following example uses a policy.
Select a policy and bring it up in an editor.
In the Policy Description area, add the following keywords:
$Date$
$Rev$
$Author$
Save these changes to the policy.
Check the project into the version control server.
Update the project from the version control server.
Open the policy in an editor and you will see that Subversion has substituted the keywords to show the following:
$Date: 2008-05-20 11:17:51 -0500 (Tue, 20 May 2008) $
$Rev: 1513 $
$Author: tpew $
You need to perform this procedure for each object for which you want to see this type of information. You can add keywords in any place where you can add text, but the object’s Description area is most accessible. The keywords are updated as you or other team members make changes to the object.