Download - How to use CVS applied to SOLab
Software Development and Version Managementwith CVS and TortoiseCVS
Madrid, 16th August 2012
Pablo Arriazu Ruiz
Possible new features for SOLab development
What is CVS?
Concurrent Versioning System.
Used to track and coordinate source code changes.
Helps the work with several developers:
• Tracks the change and who changes it.
• Allows to work simultaneously in the same source code, even in the same file.
Avoids you for keeping backups of the process.
Important tool for the Free Software Community
http://www.nongnu.org/cvs/
What is Tortoise CVS?
Visual GUI Interface (CLIENT) that simplifies the process.
Interaction with CVS server through the File Manager.
http://www.tortoisecvs.org
The Copy-Modify-Merge model
The developer downloads a working copy (checking out) from the shared repository.
The developer edits his working copy (on his computer = sandbox)
The developer finishes his changes and commits them into CVS with a log message explaining the purpose of the changes.
Other developers can ask for the changes in the library, CVS automatically updates their working copies.
If two developers commit changes in the same file, CVS detects the conflict and saves a differences file.
A developer selects what is the adequate solution for the conflict and merges both versions into a unified revision.
Starting to work with CVS: Participate in a project
In order to work as a developer of an existing project (i.e. SOLab)
Install TortoiseCVS
$cvs –d :pserver:[email protected]:2401:/CVS/ROOT/MIG login
Starting to work with CVS (2)
After selecting the project to download, appears a window that window that shows the messages that CVS usually shows in a console
It’s possible to interact with CVS in the classical way with a console (even in MS Windows using PuTTy)
$cvs checkout SOLab
Changing the content of a project
When a new file is added it must be specified
• TortoiseCVS detects ASCII/Binary
• After adding [remove] a file it’s compulsory to commit–
– add -kb for binaries
Commit after changing the content of a file
• Upgrades the revision: 1.1->1.2
$cvs add NewDocument.txt
$cvs commit [-f] –m “bug solved” NewDocument.txt
Branching and tagging
Insert a new branch for a new development concept or to maintain two different ways of it.
You can return to the trunk (head), to tags or branches, by update special command
It’s possible to get the version as it was just before a date
$cvs update –D “2012/07/19”
Merging a branch
1.- Make update special in order to have in your local copy the revision you want to merge in (generally the trunk).
2.- Look for the merge command.
3.- Set the “Start” in the revision you want to merge in and the “End” as the file you want to copy. (It could be a revision, a branch or a tag)
4.- Resolve the conflicts that will appear.
5.- Commit
But, there are more developers…
Updating the files you obtain the last situation on the repository
Some letters appear before the files:
• C – File changed in both locally and CVS
• M – File changed in local copy
• P – File had changed in CVS, so the local copy has been updated
• U – File has been created in your machine
• A – File added to CVS, but not yet committed
• R – File removed from CVS,
$cvs update [-q]
When a conflict appears
Appears when committing, merging or updating after two developers have made changes in the same file.
$cvs status
Tracking the changes:The “status” command
Status (of the files in your machine):
• Up-to-date
• Locally modified
• Needs Patch (before updating)
• Needs merge (before updating)
• File has conflicts on merge (after merging)
Tracking the changes (II):Status in File Manager
Most of the times, it’s enough with the information of the File Manager
Tracking the changes (III):What are the changes?
Log shows the comment made in every commit.
If comments are correctly you will know the meaning of the changes done without reading the code.
$cvs log [file]
Tracking the changes (IV):Who has made the changes?
Annotate allows to know the who, when and in what revision have changed every line in the code.
By default only shows the trunk’s changes. To watch the annotation from a branch add the tag –r [revision number]
$cvs annotate [file]
Tracking the changes (V):Weblog
Needs to be installed in the server: ViewVC or CVSweb.
Quick vision of the tree of files.
Possibility of setting what branch you want to see.
Shows every file log in html.
Allows to see annotate and diff from the files.
IDLdoc documents actual copy in sandbox (but it cannot be replaced by weblog)
Tracking the changes (VI):Look for the differences
You can:
• Look for the differences between your working file and any of the others.
– You can use especific programs to this (i.e. WinMerge) and configure Tortoise to open it (TortoiseCVS ->Preferences -> Tools -> Diff Application)
• You can save the revision
• The difference between a Sticky version and setting a file with update special is that it will remain without changing (although you update)
Reverting changes
Probably, the needing of going back to a previous revision will appear:
The new file will appear as revision 1.5
$cvs update –j 1.4 –j 1.3 [file]
$cvs commit –m ”reverted to 1.3” [file]
Revisions, versions? Tags
Revisions are internal characteristics of the development process, every time you change anything, it’s advisable to do it
Every time you commit the revision number (last one) increases by one: 1.1->1.2
In branches the revision number comes from the starting file, an even number setted by CVS and the revision number
Versions are deliverable snapshots of the code that are used by the final user.
• The same version of the Application can have a different name of revision for every file, but the user doesn’t matters this
Revisions, Versions? Tags (II)
A good way to preserve the vision of a program or its situation in a concrete period of time is to put tags.
But, how do you change the version.
Where I put the stable version? In the trunk and then, do I continue in a branch?
Source: OpenSource development with CVS. Moshe Bar and Karl Fogel
To branch or not to branch
Release 1.0
Release 2.0
Release 3.0
Branches, how NOT to use them
2.1 2.2
3.1
To branch or not to branch (II):A software development style proposal
The mainline is the development line.
Releases are stored in branches in order to support them and fix bugs
Development lines (unstable) are stored in branches too.
Some references recommend mainline to compile and work properly in every moment.
Source: Practical Perforce. Laura Wingerd
Minimize the number of branches
Minimize depth of branches
Use consistent tags
To branch or not to branch:A software development style proposal
The mainline is the development line.
Releases are stored in branches in order to support them and fix bugs
Development lines (unstable) are stored in branches too.
Some references recommend mainline to compile and work properly in every moment.
Source: Practical Perforce. Laura Wingerd
Minimize the number of branches
Minimize depth of branches
Use consistent tags
Some good practices
Always comment every change.
• “If you don’t have anything to comment you don’t have anything to commit”
Use tags to set up points you will probably want to go back.
• Tagging is a good way to set the version number, stability points, start of developments, etc.
Tag Root-of-(name of the branch) in the file it comes from.
Put a tag in every merge.
Commit at least at the end of the day and update every morning.
• You are not alone: in this way all the group will work with updated code.
Releases? 2.1?
A release in CVS is a copy without the administrative CVS (hidden by default) data in the working copy.
Check out in another folder, this will disconnect your copy to the server.
To change the revision first number you can use this code:
Be careful of this, once there is a file in this way, all the new files will use the same version first number.
$cvs commit –r 2 [file]
CVS as a communication tool
Several developers might want to work in the same file.
It’s possible to configure the server in order to send e-mails when a developer is working on a file.
Mails are sent only to the users that have activated the watch command in a file. It can be activated in the whole project.
This only notices when a user commits a watched file.
In order to notice when a user starts to edit: edit
If this user is going to stop editing (without commit): unedit
Watchers allows you to know who is watching that file/s
Server has to be configured to do
this
CVS as a communication tool (II):reminding people to use watch
If users don’t set edit, CVS sends a mail when commit.
Watch on makes the copy on your computer read-only.
Turns read-and-write only after edit command.
This could be unconfortable for developers
Too much mails (start editing and commiting) could make them annoying and developers won’t read them.
watch off is possible
History
Has to be activated in server
Shows every action taken in the server
Not quite useful, not easy to read the result
Mantis integration
Mantis is a bugtracking software
It can be synchronized with CVS
After commiting it’s possible to read the log message
Useful as the number of users and developers grow
Keywords in the header
Written in the header, they give information about the file last revision.
SOLab code uses $ID: $, when commiting it’s converted into:
Before commiting, delete the keyword information, this way CVS will fill it again. (only $ID: $ has to remain)
When merging and diff, they are detected as changes, just delete the information.
Other keywords: Author, Date, Revision, Source, Log
; $Id: sol_funittoseconds.pro,v 1.1 2012/08/06 12:17:08 mcosta Exp $
SOLab
It’s important to select a development methodology, especially to make the branches functionality practical.
Some of these features could be added to the SOLab coding process
They will be more interesting as the number of users and developers grow.