Source Code Management

Source Code Management

When you start programming, you do things the best way you can with you code. And along the road you gather many experiences on how things are done in a better, more efficient, more simple and elegant way.

The Version control

This comes along the road, after developing your code you realize that you need to keep a backup of it. This comes for several reasons, your workstation crashed and you lost your data, or you modified your code and now it doesn't work anymore and you can't figure it out why, or you need to return to a point in your project which to redo some calculations with the exact same code. For all this cases and many more, you need to be able to return to earlier versions of your code.

For this we tend to develop many strategies, copy our code to some external media. Then maybe get confused which was your last version, so start including the date of the code. Later you might realize that you can email yourself your code, so you have it available anywhere and email keep the timestamp, you can even benefit from including a nice message in that email about the changes to your code. You can come to learn about revision control software(RCS) and use it with online backup.

In any of the steps you are, you certainly realize already that for any software development, one of the most important tools is the version control software. They are used in virtually all software development and in all environments, by everyone and everywhere.

The main purposes of Revision Control Systems

1. Keep track of changes in the source code.
   • Allow reverting back to an older revision if something goes wrong.
   • Work on several "branches" of the software concurrently.
   • Tags revisions to keep track of which version of the software that was used for what
2. Make it possible for several people to collaboratively work on the same code base simultaneously.
   • Allow many authors to make changes to the code.
   • Clearly communicating and visualizing changes in the code base to everyone involved.

###Basic principles and terminology

• The source code or digital content is stored in a repository.
• The repository does not only contain the latest version of all files, but the complete history of all changes to the files since they were added to the repository.
• A user can checkout the repository, and obtain a local working copy of the files. All changes are made to the files in the local working directory, where files can be added, removed and updated.
• When a task has been completed, the changes to the local files are committed (saved to the repository).
• If someone else(could be yourself) has been making changes to the same files, a conflict can occur. In many cases conflicts can be resolved automatically by the system, but in some cases we might manually have to merge different changes together.
• It is often useful to create a new branch in a repository, or a fork or clone of an entire repository, when we are doing a large experimental development. The main branch in a repository is called often master or trunk. When work on a branch or fork is completed, it can be merged in to the master branch/repository.
• With distributed RCSs such as GIT or Mercurial, we can pull and push change sets between different repositories. For example, between a local copy of there repository to a central online repository

Software Sharing and contribution

It's easy when you rule over your own repository, you do things the way you believe is best and that doesn't bother anyone. But when you share your code and aim for some cooperation, well, then everything bothers everyone. And there are many things, small and big details you need to agree with everyone and then later enforce to every project contributor old.