This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I was under the impression that cvs could merge concurrent code changes to one file. For example, Bob makes changes to SomeFile.java and commits those changes in cvs. Anna was also working on SomeFile.java at the same time Bob was. When she is ready to commit her changes, she first executes the cvs update command and gets a 'M' message for that file. I had thought this 'M' meant that Bob's changes were successfully merged with Anna's file and that she could now safely commit her changes, preserving both Bob's last commit and her changes. However, I have had numerous problems with this situation in that I have overwritten other developers' changes. Does cvs actually have this merge function I was told it did? What could be going wrong?
The merge takes place on your machine when you update the file. If there is a conflict (an attempt to change the same line of code by two people) than CVS puts both in the file with delimiters showing what was in the CVS version and what was on your machine.
You can't commit the file until you've resolved the conflict.
Also if someone else commits changes to the file, you won't be able to commit until you've updated to bring their changes into your working copy.
The "M" annotation means "locally modified", not "Merged". If you do an update and you see
That means you've changed it, but nobody else did.
One way to overwrite someone's changes is to modify a file, and have it unsaved, open in your editor. Now do an update, to get someone else's changes. Now save your file, overwriting their changes in your local copy, then commit, which pre-empts their changes with yours.
The right thing to do is save your changes, then update, then (if necessary) repair conflicts, and then commit.
Thanks. The problem turned out to be something else entirely. In the words of an astute colleague:
" We've finally arrived at how the changes got overridden. CVS stores all version information in a file called CVS/Entries. When two people share the same machine, they do an update in the [dev] folder thereby the version information will always be the latest. However, since they both work with older versions of the files, CVS has not way of knowing that and when they copy the files back to [dev], CVS will treat them as current and not merge any changes back. The solution is either get new machines or set up separate log-in accounts."
author and iconoclast
In my opinion, your setup seems to completely circumvent the advantages of CVS. To avoid this problem in the future, you should set up local CVS clients on the machines where the code is edited. This way each developer can check out their own local copy. Alternatively, each user can have separate accounts on the Linux server and checkout local copies to their user directories. However, care should still be taken to NOT make copies of any local CVS copies because the same thing can happen again.