The larger the project, the more developers are involved; thus communication between the team members can become a problem. Making sure everyone has the latest version of source code, avoiding duplication of effort and ensuring that one developer doesn’t overwrite other developers; work becomes complicated.One way to manage this complexity is by using a version control system.
Version control allows you to store a source code in a central location, usually called repository, so all team members have access to the latest versions code.It automates the process of updating your source code to incorporate the latest changes done by your team members; allowing you to push your changes into the repository so other members of the team have access to it. More importantly, it provides you with the historical data regarding the changes made to the source code.
Subversion http://www.collab.net/)) is one example of a Version control systems that can be used for such purposes. Before developer can do anything with Subversion, he/she needs to create a Subversion repository.The repository is the place where the project source code will be held.Traditionally, most people create three top-level directories in their repository: one named /trunk to hold the main copy of the source code where most development happens, one named /branches to hold separate lines of development (this just a copy of /trunk), and one named /tags to hold copies of the source code as it exists at significant points of time.
The basic workflow begins by importing (svn import) the project source code into the repository, and then the next step is checking out (svn co) a working copy into your filesystem; The files and directories in your working copy almost correspond to files and directories in your Subversion repository.
Once you have a working copy, you can edit the files, make changes to the files, and add more to them, then commit (svn ci) those changes back to the repository so others can see them. In the process of making your changes, you can ask Subversion to let know you about the status of your changes, view the difference between your current version and the version you checked out (or any other revision), or update (svn up) your working copy to take into account other users’ changes. These actions comprise the majority of the Subversion workflow. Best Practices When it comes to committing your changes it is always advisable to:
Commit Early, Commit Often: Try to structure your changes so that they can quickly be committed to the repository.The longer the change is sitting in your working copy, the more risky it becomes for several reasons.First, the repository is likely to be better backed up than your local copy.Second, transferring the change from your working copy into the repository means that you no longer have to worry about another developer making a change that could conflict with your work, which can result in lost time resolving these conflicts.Third, The sooner you get your change into the repository, the sooner your colleagues will see the change.
Make Small, Atomic Changes: Making small changes offers many advantages.First it makes it easier to view the changes using (svn diff) command. Second, it makes it easier to revert back to the previous version. Third, it will be easier for your team members to understand the changes.
Use Meaningful Log Messages: When you write meaningful messages to accompany your commits it is easier to dive in and provide helpful feedback.More importantly, it is possible to look back at the history of your code base and determine not just what was changed, but also why it was changed.