3.6. Working together
3.6.1. Problem?
If more than one person can edit a file, you're in for some problems. Issues like, "what if person A and B edit the same file at the same time and then commit their changes, what version will eventually be stored on the server" need to be resolved.
3.6.2. Editing the same file at the same time
CVS handles the problem of editing the same file at the same time for us.
Lets say person A and person B are editing the same file readme.txt revision 1.4. When person A is ready he commits the changes. The revision gets changed to 1.5 because of that. Person B, not knowing that person A edited the file, tries to commit his changes only a few minutes after person A, and gets an error:
cvs server: Up-to-date check failed for 'readme.txt' cvs [server aborted]: correct above errors first!
WinCVS has "seen" that the revision 1.4 wasn't the most recent anymore, since the server has a revision 1.5 of file readme.txt.
Person B now selects Modify > Update Selection in WinCVS, and sees this output:
RCS file: /cvsroot/sf2k/Version_4/readme.txt,v retrieving revision 1.4 retrieving revision 1.5 Merging differences between 1.4 and 1.5 into readme.txt rcsmerge: warning: conflicts during merge cvs server: conflicts found in readme.txt C readme.txt *****CVS exited normally with code 0*****
The conflict is no error (CVS exited normally), but something that has to be resolved. The fact that there is a conflict is indicated by both the status of the file and the icon that is used in WinCVS:
If you open the file you can see the conflicts indicated like this:
<<<<<<< readme.txt text 1 ======= text 2 >>>>>>> 1.5
where "text 1" is the text like is appears in your local copy, and "text 2" is the text like it appears in the revision (1.5) on the server.
Resolving the conflict is easy: just edit the file so that the changes are merged, and then commit the file back to the server. The revision number then gets updated (again) so that the final revision number in this case is 1.6
If person A is smart enough to run the "update selection" command before editing the file again, he will see the new revision 1.6, otherwise he'll get the same possible conflicts when he tries to commit his version again.
This example shows that it is wise to update your local copy often when there are more developers working on the same code.
3.6.3. Editing / Watching / Locking
In the previous section I explained what happened when two people are editing the same file. CVS default doesn't use locking when you check out files. All developers are indicated as being editor. If you select the option Trace > Unedit Selection you'll notice that nothing happens, you'll still be indicating as editor.
To be able to use the Unedit command, you'll first have to set a "watch" on the files. You can find out if you already have set a watch on a file by choosing:Trace > Watchers of selection.
I encountered problems when trying to set a watch on the complete directory at once in Version 1.2. A workaround is to issue the correct command in the commandbox itself. In this case, you can set a watch on all the files in module Version_4, including new files you might add and subdirectories with:cvs watch add -R Version_4 and remove it again with: cvs watch remove -R Version_4. Make sure that while issuing these commands you've got the root folder selected:
Now that you've set a watch on the files in the module, you can select to edit or unedit the files. First you have to select to edit the files. To do that for all the files at ones, click on the Version_4 folder and select: Trace > Edit Selection. After that you can select to Unedit the files by selecting: Trace > Unedit Selection. Others can see who is editing a file by selecting Trace > Edtors of selection .
This indication doesn't prevent others from editing and updating the file while you are editing it.
To prevent that you'll have to lock the file. You select Trace > Lock Selection to lock the file and Trace > Unlock Selection to unlock it again.
When a file is locked, other developers can still edit their local copy of the file, but can't commit the changes they made to the server as long as you have locked the file. Locking too many files can also cause problems because there is no visual hint for the other developers that a file is locked, not even after updating the local files with the ones from the server (where the locking information also is kept).
There are a couple of ways to find out if a file has has been locked: 1) try to lock it yourself, you'll receive an errormessage if someone else already has locked it, or 2) Select Query > Log Selection. The list you can see coming by also contains the locking information.