Weather schmether

When I was working on the roof I became a very keen follower of weather forecasting. Still I got caught short by unexpected rain many times. I find myself beginning to wonder if the Met office has had its budget cut and have, in desperation, resorted to using a crystal ball.

But today I decided to take the forecast seriously. I was due to go for a run, and I really, really, do not like running in the rain. The weather forecast predicted showers for the day. So after taking the girls to school I looked up at the clear blue sky and decided that this was the time to get going on that run. Before the bad weather set in.

Some 30 minutes later I was more than a little unhappy when I found myself far away from home - with hail pelting down all around. I have never run in a hail storm before, and it was an interesting experience. There was no cover, and the hail persisted until I got home. Whereupon it promptly stopped, and the clear blue sky returned. And remained above for the rest of a beautiful day. *Sigh*.

8:55:34 PM    

When connecting to CVS, we were getting the following error message:

cvs status: conflict: <<file>> created independently by second party

Until now I have just checked my code in and out of version control, and always had someone else to administer it and sort it out. My Wernher Von Braun past...

"The rockets go up
who cares where they come down
That's not my department
Says Wernher Von Braun" (Tom Lehrer)

But this rocket was coming down squarely in my back yard. Being new to Linux, I had to do a fair bit of spelunking to work out what was going on. After reading the CVS documentation I formulated the following theory:

• Party 1 checks a project into CVS, but does not check in the <<file>>.

• Party 2 checks code into CVS, and includes the <<file>>.

• Party 1 tries to check in a file with the same name & path as <<file>>.

The error message is displayed to Party 1 as CVS is smart enough to realise that here be a problem. Having got this far, I formulated the following fix.

Party 1 is to:

1. Rename his local file and then "cvs remove" it to undo the add

2. Do a "cvs update" to get the file checked out of the repository, and then compare the local file to the repository file.

3. Party 1 can then resolve conflicts however he likes.

I still believe the above to be a valid cause and fix for the message being displayed. However, after looking at the <<file>> in the repository the above theory was shown to be totally wrong in this instance. All that hard work. Damn. Back to the manuals.

It turns out that the real problem was a permissions one. A trap for unwary newbies! CVS adds new files to the repository under the default group of the user performing the addition. If CVS users belong to different default groups CVS additions are not readable by the developers in the “other” default groups.

The quick fix was simply to change all the CVS users to share the same default group, and to run the “chgrp -R <<defaultGroup>> .” command on the repository. Lo! All became sweetness and light.

But if it turns out that this fix isn't suitable in the long run the following article presents a hack that may just be the ticket:

http://kered.org/article-2004.01.20-Multi-Group_CVS_Administration_HOWTO.html

1:31:04 PM