Class 12 – Version Control Using Subversion
When projects require several developers (i.e. designers, developers, html coders, etc), they may run into situations where multiple people try to edit the same file at the same time. This could be problematic, since one developer could easily overwrite another’s work.
To prevent one person from overwriting another’s work, most teams of coders use some form of version control. Version control software allows multiple people to simultaneously work on the same files while not overwriting each other’s work.
Subversion is probably the most popular version control software:
http://subversion.tigris.org/
You can find the Subversion online manual here.
The Repository
Subversion uses a type of client/server architecture. The permanent location of all files is on the server, in what is called a Repository.
The Repository has the current version of all files, as well as all the older versions of the files stored in a nicely organized way. It keeps a permanent record of any changes to the project.
Clients can always get the latest copy of the files by copying them from the Repository. So developers generally make changes to files on their local machines, and then upload them to the Repository so that other developers can get the lastest version of the files.
Internally, the Repository in Subversion has three subfolders: “trunk”, “branches”, and “tags”.
The “trunk” is the main folder that always has the latest copy of the main version of the code.
The “branches” folder is used if you decide to fork your code and simultaneously work on two or more different variations (or branches) of your code.
The “tags” folder allows you to give nicknames to prior versions of the code for easier access later on: for example, you may decide to call revision #12 the “gold_release” with a tag so that it is easier to remember than a number.
In general, for a simple project, you will work with code in the “trunk”, unless you are an advanced user.
The Client
Your local computer runs a Subversion client that automates the common tasks that you will need to do when using version control. The recommended client for Windows is TortoiseSVN. For Mac, you should check out SvnX.
Any client will easily allow you to run the basic Subversion commands:
- checkout - this command is used to get all the files from the repository at once and download them to your client. You usually run it once at the beginning of development to set up your working copies of the files
- import - this command is used to import files as a batch into the Repository. It is usually used once at the beginning of a project that has already begun without version control.
- add - this command adds a file to the repository.
- update - this command updates all the files on the client machine with the latest version from the Repository
- delete - this obviously deletes files
- commit - permanently store any changes in the Repository. Note: you need to commit after every modification, merge, add, or delete in order for those changes to be permanently stored in the Repository.
Working Copy
When a developer downloads the latest copy of the files from the Repository, they are placed in what is called a Working Copy. This is exactly what it sounds like – a copy of the original files that a developer can use to work on her client machine.
Once a developer has finished modifying the files, she has to then upload them back to the Repository so other developers can see the changes.
Checkout
When a developer starts working on a project that is using version control with Subversion, the first thing they will need to do is get a copy of the latest version of all the files in the project. This is called the initial checkout.
Any Subversion client, like TortoiseSVN or SvnX, will have an option to checkout the files in a repository.
This command is usually only run once to do the initial setup of the Working Copy on the client machine.
Update
To get the latest copy of files from the Repository, a developer runs a command called Update. This automatically downloads the latest files from the Repository.
Developers should run an update immediately before editing any file, and again immediately before Committing any changes to the Repository.
Commit
When a developer has finished making changes to her Working Copy of the files, she first runs the Update command to make sure that nobody else has modified the same files she is about to upload, and then runs a Commit command that automatically uploads the changed files to the Repository.
Conflicts
When two developers have modified the same files at the same time, and then they both Commit their changes, the second developer to commit his changes will experience a Conflict. Usually the work the developers have done is in different parts of the file, so Subversion can automatically merge the two versions together.
However, in some cases Subversion cannot figure out how to merge the two versions of the file, so it asks one of the developers to manually merge the two. Subversion will show you the difference between the two files, and you can usually easily see what has to be done to get the two versions to merge correctly.
Once you are finished merging, you must of course commit any changes in order for them to be permanently stored in the repository.
Workflow
To sum it up, here are the usual steps you will take when working on code that is held in version control:
- update to the latest version of code
- modify the code
- update again to check for any conflicts from other people’s changes
- merge any conflicts that have arisen from other people’s modifications
- commit your changes
Related posts:
Tags: class 12, subversion, version control
Loading ...