I can’t imagine professional IT project development without source control. No matter whether you’re working on a small personal project or on a large commercial application, source control is something that helps you to manage bunches of constantly changing code among multiple developers. It is so-to-say UNDO functionality in the programming process.
Source control has a repository where it holds the developed files and the data of your development process. Each developer works with her own copy of the repository. The basic work under source control looks like this:
- You get the files from the repository to your local copy. This process is called “check-out” (for the first time) or “update” (for the next times).
- You edit files.
- You check the status, what files you’ve changed. If some new files were created, you might add them to the source control as well, or you can set them in the ignore list not to show them in the status report anymore.
- Then you send the changes from your copy to the repository. This process is called “commit” or “check-in”.
With each committing, source control creates new versions of your files. The commit generates a new revision which has an incremental number. If you make some mistake, you can always rollback to a previous state of your development by the number of revision or by date the committing was made. With each committing you can (and should) write comments, what was changed for that revision, so it’s much easier to find out to which revision to rollback. Also source control usually can show the changes of the same file between two different revisions.
The repository might be set up either on the same computer or on the distant server. Files can be controlled for one person as well as for a large network of developers.
When a couple of developers modify the same file, the source control tries to merge the changes in the file. If it’s not obvious, how to do that, a conflict is thrown, and developers have to solve it manually. Source control doesn’t accept any conflicts to the repository. They have to be fixed on the local copies before being able to commit.
When the project is developed by multiple people, it is possible to check what changes were done by whom. There are some other functionalities of source control as tagging all the files of the current revision with some string (i.e. release number); creating different branches of the same project, or merging two different branches into one.
From a bunch of source control systems, I prefer Subversion (SVN), as it is full-featured, convenient, stable, and last but not least – it’s free of charge.
At the studio, where I work, we use SVN for CreativeCityBerlin and other Django-based projects. The repository is in a secured server requiring authentication for each user. We use a wide range of SVN clients on different platforms. I usually use the standard command-line SVN client for my own development environment (it’s on Mac OS X) and for the public server (running on Linux) where the websites are hosted. Some of us use ZigVersion SVN client for Mac. Some are using TortoiseSVN for Windows.
As a small step towards continuing developing my Halma game and other personal projects, I installed TortoiseSVN on my personal laptop as well. I am not the only person to approve that TortoiseSVN is the most user-friendly SVN client on the Earth at this moment.
It is fully integrated into Windows Explorer and it is very intuitive. All the source-control functions are accessible on the right-click menu. The statuses of the files are marked with indicators attached to the file icons.
After installing TortoiseSVN onto my PC, I created a repository for my Halma game locally. And also as a test I created a public repository on Google code for my Klãva project.
If you haven’t started using any source control, I encourage you to do that ASAP. Version control can be successfully used not only by IT developers, but also by writers, digital artists, or composers.
Tags: IT, programming
Loading ...
