CVS is extremely popular for configuration management (with Subversion quickly gaining speed). It uses “optimistic locking” in which multiple users can work on the same file at the same time, and any conflicts are resolved when the file is “checked-in”. This works wonderfully for text files in which multiple user’s changes can be merged together. This doesn’t work well for binary files. However, for best configuration management, plans, designs, and other artifacts should be placed under version control with the code they affect. So in our projects, the question always arises: How do you resolve CVS commit conflicts for binary files (specifically Word documents)?
So let’s say you’re using TortoiseCVS and decide to work on a file named “ProjectPlan.doc”. Dutifully, you do a CVS update to get the latest version, make changes in Word, do a CVS commit and encounter:
cvs server: Up-to-date check failed for ‘Documentation/Plans/ProjectPlan.doc’
cvs [server aborted]: correct above errors first!
TortoiseCVS is nice and gives us the additional message:
Tortoise Tip: Someone else has committed a new version of one or more of the files you are trying to commit. You need to do a CVS Update and then try to commit again.
So what do you do? A CVS Update won’t work because CVS can’t merge the binary Word document changes. (If you try a CVS update, it will rename your existing modified file to something funny (“#ProjectPlan.doc.1.1” in my case), get the latest copy of the CVS version, and display a warning.) But Word can do the merge for you! So if you have a conflict with a Word document, do the following:
- Rename your modified local copy
- In my case, I renamed “ProjectPlan.doc” to “ProjectPlan-mod.doc”
- By renaming the file, we don’t have a “ProjectPlan.doc” file in the directory anymore (this is good since it prepares us for the next step).
- Do a CVS Update to get the latest CVS copy
- This will place the latest version in “ProjectPlan.doc”
- Open the latest CVS copy (“ProjectPlan.doc”) in Word
- In Word, select Tools/Merge Documents, select your modified copy (“ProjectPlan-mod.doc”), and click “Open”
- At TCG we routinely leave “Track Changes” on in our checked in documents to facilitate easy comparison. If both documents had their changes tracked, the changes will merge nicely (though you will get a warning).
- Review your changes to make sure they were what you wanted
- Save your newly merged copy (“ProjectPlan.doc”)
- Do a CVS Commit on your newly merged copy (“ProjectPlan.doc”)
- Delete your unneeded modified version (“ProjectPlan-mod.doc”)
Congratulations!
Alternately, you can just implement file locking (a.k.a. “reserved checkouts”) for all of your binary files so that you don’t get into this situation to begin with.
Just a suggestion 😉
Good point. If you prefer “pessimistic locking” you have two choices:
— Use the CVS Watch/Edit capability
— Use Reserved checkouts (see http://www.thathost.com/wincvs-howto/cvsdoc/cvs_10.html )
I just have a strong fondness for “optimistic locking”.
I too am a big fan of optimistic locking. It tends to be my default posture for projects using CVS or SVN unless I’m dealing with a team that just can’t handle that type of responsibility. However, after a couple of conflict/rename cycles, I tend to get a bit pessimistic.
You’ve won me over: but I can have it both ways now! In our repositories, we put project plans, schedules, and other binary work products in a “Documents” directory, while source code is in other directories. Thanks to the relatively new watch/edit/unedit feature I can essentially get pessimistic locking for my binary documents (through TortoiseCVS).
I upgraded my CVS server to 1.11.22 (to support “cvs watch”) and set “cvs watch on” for our Documents directory. When you do a checkout, files in that directory are read-only until you run a “cvs edit”. TortoiseCVS will only let one person “cvs edit” a binary file. While it’s a client-based restriction, it functionally keeps two people from editing the same binary file simultaneously.
The file is unlocked once the user does a commit or “cvs unedit”. We’ll see how well this works…
I am using CVS for my project. It worked fine for me for a long time but its been few days em getting a commit error. I get this error when i edit any of my project’s file, hence unable to commit after i edit a file. I had deleted the whole folder from my system and used check-out option to get all latest files from the server but again when i edit any file, it gives me the following error.
“””””“cvs commit: file ‘templates/admin_tpl/cms.tpl’ had a conflict and has not been modified
cvs [commit aborted]: correct above errors first!””””””””””
error… Any help??
THanks in advance
Is “templates/admin_tpl/cms.tpl” one of the files in your repository? If so, in the very worst case you can:
* find the file[cvsroot]/[project]/templates/admin_tpl/cms.tpl,v on your CVS server,
* move it out of the cvs repository
* check out yet another copy of the project (now without cms.tpl), keeping the old cms.tpl somewhere
* and readd cms.tpl using a “cvs add” to the project
The downside is that it you will lose any comments associated with the file.