- Subversion: A Great Product
- Repository and Working Copy
- Creating the Repository
- Creating a Share and Mapping a Network Drive
- Structure of the Working Copy
- Checking Files In and Out of the Repository
- Getting Other Peoples Changes
- Adding New Files
- Getting Change Differences for a File
- Getting Information About a File
- Backing up Subversion Repositories
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Checking Files In and Out of the Repository
You now have a repository set up and shared out on your network. You also have a local working copy on your client machine. Believe it or not, that’s enough to get you started with Subversion! For me, the sign of truly excellent software is this type of low entry cost. In other words, you do a simple installation followed by two or three equally simple setup steps and then you’re ready to use the features of the product. How often have you spent long tedious hours trying to bend some overly complex product into operation? Probably too many. I always say: If software isn’t simple, then either it doesn’t work or its authors don’t understand the problem they’re trying to solve.
It’s important to remember that the working copy represents the client view of the repository. So in a way all the client working copies are inextricably interwoven with the repository, which provides a clue for how changes are committed to the repository. You simply change to one of the folders underneath the "trunk" directory and enter the following command:
svn commit –m "My changes."
This command transmits any and all changes to the repository. The really clever thing is that the Subversion client software works out which files have changed and sends the details to the repository. It’s the same mechanism if you’ve modified one file or one million files.