Differences between revisions 2 and 3
Revision 2 as of 2011-01-07 18:08:57
Size: 4267
Editor: YoichiAso
Comment:
Revision 3 as of 2011-01-10 17:25:28
Size: 4300
Editor: YoichiAso
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:

[[/LCGT/SVN/Reasoning|here]].

Version Control System for LCGT

This page contains information for using version control system, subversion, for various LCGT tasks.

Introduction, why version control system ?

Version control system (VCS) is a computer tool to manage the history of various files you work on. Usually, files are documents or program codes, but you can use it for managing virtually any type of files. It keeps track of the changes you make to the files and let you roll back to any previous version if you want. The VCS is particularly useful when several people are working on a single set of files, for example, a group of people writing a paper, or several people developing a simulation code together. Subversion (svn) is a popular VCS and used by many projects around the world. There is an svn repository for LCGT. LCGT collaborators are strongly encouraged to use this svn repository for any applicable tasks.

here.

It is probably easier to illustrate a sample use case with an example. Suppose two people, A and B are working on an interferometer simulation program. The simulation program has three files, file1, file2 and file3. Initially, exact copies of those files are installed to the computers of A and B.

Now, A started to edit file1 to implement a new function. About the same time, B started to edit file2 to add his own changes to it. If they continue to work like this for a while, they will eventually have two very different sets of files. There may be some inconsistent changes made by them to their own version of the program. After a while, it will become very difficult to merge their works back to a single program.

If they use SVN, the story will be different. They will first set up a repository and store the initial version of the program in it. Before making changes to file1, A will check-out a local copy of the files to his computer from the repository. B will also check-out his copy of the files from the repository. Then they will make changes to their local working-copy of the files. After making a change to file1, A will commit the changes to the repository. The "commit" will propagate the changes made to A's local copy of file1 to the file1 in the repository. SVN automatically records the difference between the original file1 and the updated one (to keep track of the changes). So you can always roll back the file1 to the original version if you want. Before start working on the program, B will first update his local working-copy. When commanded to "update", svn will compare the working-copy and the repository. If it finds updated files in the repository, it will update the working-copy accordingly. Therefore, B can be sure that any changes previously made by A is incorporated in his working-copy. After B edited file2, he will commit the changes to the repository. This change is propagated to A's working-copy when A performs "update" next time.

By making sure to commit and update periodically, the working-copies of A and B are roughly synchronized. Moreover, it is easy to see what changes were made by your colleagues (diffs between versions) with svn, so that you can always be aware of what other people are doing.

Of course, there is no magic behind the svn. With svn, you can still break compatibilities between files, or make the program impossible to compile or run. This can only be avoided by communication between the collaborators. However, svn can in some sense enforce the communication, because if you make a change which break compatibility with other parts of the program, other people will see the problem immediately and complain. When you are working on your own version of the program by yourself, you in general are less careful about making incompatible changes, as it only affects you and you know what you did exactly. However, when working with svn, you are more aware of other people and feel more obliged to inform other people of what kind of changes you want to make. This may slow down the development process a little bit, but in the long run, it may save a lot of time, because your changes are always checked by other people, and it is less likely for you to make stupid mistakes.

LCGT SVN quick start

See here.

LCGT/SVN (last edited 2021-06-03 12:14:16 by Ken-ichi Oohara)