Version control

From SourceWiki
Jump to navigation Jump to search


Version control is the management of the files within a project. It is mostly used for code development. Version Control has many various obvious advantages, e.g.:

  • versioning (!): every change done to the project is monitored (by whom?, when?) and documented (why?). If a particular change is subsequently judged inappropriate, Version Control makes it easy to roll back to the previous version for instance.
  • quality insurance: mainly because of versioning, see above.
  • code sharing: although version Control can be used for simple project with only one developer for its versioning capabilities, it is almost a requirement when the code is shared with other developers. Version Control allows the developers to keep an up-to-date version of the project, incorporate the others' changes regularly and making development and bug tracking easier.

Wikipedia has a good description of version control with useful links.

The Version Control system installed on our server source is Subversion. This is a centralised Version Control system, which means that there is a central copy stored on a server and all changes go to the central copy before going to the different developers.

Common terminology

[for a centralised Version Control system, such as Subversion used on source]

  • repository: the project as it is stored on the version control server. It contains all files and their history.
  • working copy: local copy of the project. This is the copy stored on the developer's filespace that is used for development.
  • checkout: importing a project into a working copy.
  • commit: sending local changes to the repository.
  • update: importing changes from the repository (made by other developers) into the working copy. To minimise conflicts, it is advised to update very often and incorporate co-workers changes.
  • conflict: describes the state of a file that has been changed in the working copy and on the repository. Simple conflicts are usually handled automatically by the Version Control system, e.g. when you have modified the top of a file and somebody else the end of the same file. More complex conflicts are flagged by the Version Control system and need resolving before the next commit.