Fog Creek Software
Discussion Board




For the 4,532,198th #$*@!!%* time, check CVS!!!

Pardon my rant...I simply cannot stand it when people don't check CVS (or your other favorite source control system) before making wild accusations about breaking the build!!!

Scenario: I create a new package, build it out, test it, and merge it into the main working branch in CVS.  Our supposed "senior" developer then storms into my office, barking about how I broke the build.  I then double-check things, and ask as sheepishly as possible, "did you do an update from CVS?"  The genius starts to say something (again, in that annoying barking tone), and then starts to stutter a little.  "Uh, well, no...ah, well, let's see if that fixes things..."  He disappears for a few minutes.  I go to check up on him, and he grunts something about everything being in order.

This is literally the fourth time this has happened in four days.  I'm seriously tempted to barrage him with emails every time I commit anything into CVS, and maybe he'll get the picture.

I'm sure some folks will say that it's only courteous to notify the team when you commit something, but doing so in a team our size would cause everyone to lose an hour or two a day dealing with the email load.  Sometimes people should take a minute to think about what they're doing before blaming others.

Chas
Tuesday, April 01, 2003

I would tell him flat out that you don't appreciate his tone and he darn well better check CVS next time before storming into your office and wasting your time.

Mark Hoffman
Tuesday, April 01, 2003

At my office, we have a script run on commit to mail everyone on a list about cvs checkins. Everyone on the list just runs filters on the subjects in their favorite mail client to avoid mailbox clutter. Seems to work well and helps to alleviate this kind of frustration.

Andrew Murray
Tuesday, April 01, 2003

I think it is reasonable to expect team members to check CVS before doing a build, and I agree that the e-mail headache is not worth it just to coddle the one or two people who won't get with the program.

The storming in and yelling at you is wrong on several levels, but I'm not sure the direct approach (confronting him) would work, since it is likely he'll get offended and not listen to your concerns.  One solution might be to email him and say something like "I've noticed that there have been a couple times when something I committed close to a build isn't picked up and breaks the build.  Would it be helpful if I sent you an e-mail each time I commit something?"

This approach (a) puts it back on you, (b) puts the burden on you and (c) points out how silly such a scheme would be by laying it out in plain terms.  Either he'll get the message or he'll ask you to email him each time, which takes you two seconds and should ensure that he doesn't bother you in the future (because now he has no excuse).

Good luck - what a nasty situation!

Lydia
Tuesday, April 01, 2003

How'd the other guy get only some of your changes but not all of them? He'd need to do a cvs update in either case, right?

Also, is this talking about daily builds, or an individual build. The daily build system should be set up to do a full get of all files every time. Don't try to get just the changes; we tried that route once, it wasn't pretty.

Chris Tavares
Tuesday, April 01, 2003

It might be one of those junky incremental compile tools that IDEs have.  "Oh, um let me compile this one file..."  This was the culprit behind most false accusations I've seen.

Tj
Tuesday, April 01, 2003

Chris,

I gather that he does updates selectively, perhaps where *he* thinks that an update is warranted.  I think that this is connected with modifications that he makes that are in conflict with changes that have already been committed; he gets an update of the problematic file, fixes the conflicts, but never gets other changes in other files.

Chas
Tuesday, April 01, 2003

It is pretty common to get a "selective update", using any SCC tool.  Generally this happens on file checkout.  Say you're using a development snapshot of the code as it existed two days ago -- checkout a file and that file will be updated as of now, the rest will not.  Try to compile now, and if the changes in the checked out file rely on changes in other files, things fall apart.

I agree that one should always do a full local update before making "build-breaking" accusations.  If for no other reason than to avoid looking like an idiot. 

Storming in on someone and shouting accusations is completely unprofessional work conduct regardless of the reason...even if you were at fault.

George McBay
Tuesday, April 01, 2003

He updates where he things it is needed.

I alway roll my eyes at people like that. He has to guess. The tool KNOWS EXACTLY what's changed. Why isn't he using the damn tool and saving his brain for the important stuff?

Whacko. Just Whacko.

Chris Tavares
Tuesday, April 01, 2003

George,

This "check-out before editing causes compiler errors" make me happy I use CVS (which doesn't have an explicit "check-out" step that pulls you to the latest version). :)

Brad (dotnetguy.techieswithcats.com)
Tuesday, April 01, 2003

yeah, is he either updating only a portion of CVS, or are you commiting bad code then recommiting a fix?  I don't think the latter is his fault, (although he should be more polite) but if he didn't update everything, and this has happened more then once, he needs to go back to college (oh wait, they don't teach you that stuff there. :-)

Vincent Marquez
Wednesday, April 02, 2003

Chas, just print out something in big letters which says "Have you checked CVS?" and show it to him when he barges in. Then when he leaves hold up the second piece of paper to his back which says "F*ckwit. That's the Nth time." (just keep adjusting N with a red marker pen).

(Childish? Yes. But funny, particularly if you share your office with other people.)


Wednesday, April 02, 2003

> I'm sure some folks will say that it's only courteous to notify the team when you commit something, but doing so in a team our size would cause everyone to lose an hour or two a day dealing with the email load.

Did you know that you can configure CVS to email out all commit messages?

You need a line in your CVSROOT/loginfo file like:
^ProjectName  /usr/local/cvs/CVSROOT/sendcvsmail %s mailinglist@yourdomain.com

There should be some documentation on this in the depths of cvshome.org.

Colin MacDonald
Wednesday, April 02, 2003

I guess one should get latest versions of everything every morning -- I have task scheduled to run every morning in 4:00 to sync my copy of sources with source control database... Off course, this doesn't update files I checked-out, but it is not a problem because it very rarely happens that two developers are working on same source file...

Plus, if you have lot of build breaks and similiar situations during development, it usually means that either a) someone didn't assigned tasks properly (meaning two or more developers are working on same component); or b) someone did poor job designing whole thing and left components without clear interfaces -- so it forces developers to change them on the fly...

Srdjan
Wednesday, April 02, 2003

Colin,

While that is a nice feature of CVS, I don't think it addresses his stated problem -- in fact it probably makes it worse.  I don't think he was complaining about having to send the email out, but rather having everyone deal with the incoming spam when the project is experiencing heavy activity.

George McBay
Wednesday, April 02, 2003

With a bit of work, however, you can get check ins mailed in digest form to all the developers in your group, so that as a general part of the work day you do a once-over of what your coworkers checked in yesterday.

Admittedly, this wouldn't help the incident described in this thread, but its worth keeping in mind if you want some form of informing people what's being checked in but don't want to spam them all the time.

Srdjain (spelling?): the large project I work on has some components which are largely seperate and some areas which any number of people might need to touch for various reasons -- so I've run into this exact problem with some regularlity myself. I just suffer a full update and rebuild, so *shrug*

Steven C.
Wednesday, April 02, 2003

I'm going to presume that it's your programmer's local build that breaks. Also that the reason he sees a failure is that someone (in this case you) has made a change so that when he compiles, a discrepancy between code in the repository and code he is working on causes his local build (which worked fine ten minutes ago) to fail.

While I'm certainly not suggesting that rants and accusation are justifiable, if the scenario I described above has happened four times in four days I wonder if the source repository is being updated a bit too frequently, or maybe that there is too much interconnection between modules.

David Clayworth
Wednesday, April 02, 2003

As long as the code you check in WORKS, there is NO such thing as "too frequent source checkins".

Well okay, maybe there is -- but I sure can't think of why it would be bad in general. Care to give a reasonable example?

Steven C.
Wednesday, April 02, 2003

Ummm well you should check out test (fix collisions) then check in and if its a critical section lock it.

But as the original point was that it was a tested build, then the point is true and is always true, check out before doing anything.

Simon Lucy
Wednesday, April 02, 2003

Steven C.: Spelling is correct, my name is Srdjan :) (actually, Srđan, but I live in US, where 'đ' doesn't exist and alternative spelling is 'dj').

Srdjan
Wednesday, April 02, 2003

Joel, it seems that your forum doesn't support Unicode (See my post above)...

Srdjan
Wednesday, April 02, 2003

[Testing: đ is a d with a horizontal line through the ascender.]

Martha
Wednesday, April 02, 2003

"There's no such thing as too frequent checkins. Can you give me an example?"

I'm assuming here that the way the team works is that they check out part of the code they are working on, and when they do a local build the make local object code for the routines they have checked out and link against central object code for the rest. Now for any method you call that you have not checked out, if its interface is modified by someone else, your local build is going to fail the next time you compile. You are going to have to fix this by stopping what you are doing, making modifications to deal with the problem and then going back to what you were doing. If you are lucky running CVS update or similar will deal with the problem. In either case its annoying if you are in the zone.

I would think that if this problem is happening once a day then you could either batch up the changes so that you only checked in once every few days (obviously not possible if other people need the fixes) or possibly your classes are too tightly coupled. I'm not saying that either of these are necessarily true in Chas' case. In any case it doesn't excuse a daily rant. Just a suggestion.

David Clayworth
Thursday, April 03, 2003

Interesting -- I suppose I'm blinded by the way we operate where I work: everyone has their own local checkout of the source. So presuming you update your entire checkout, you won't have any problems compiling your changes. The most you might have to do is update before you commit (which is good practice anyway) and make sure someone else hasn't changed an interface you were relying on -- although if you get emails when things are committed, you can just make sure none of the files you utilize were changed.

In any case, I can see why in the system you describe frequent check ins are to be avoided.

I must say I prefer my system though. :)

Steven C.
Thursday, April 03, 2003

We solved this problem -- if I understand the problem -- at my last company by having "clean build times."  All check-ins had to be during the first half of every hour; during the last half of the hour, any complete check-out of the application should result in a clean build.

It worked reasonably well.  There were times when folks forgot, but that was fairly uncommon.

Brent P. Newhall
Thursday, April 03, 2003

Steven C

I prefer your system too, and we use it. If we didn't we would probably go to a system where you partly linked against a clean version that was built overnight, rather than whatever was most recently checked in. That way all your pain occurs once a day first thing in the morning.

I'm presuming Chas works the way I described  because I can't see how he could have the problems he did otherwise - unless his 'senior programmer' comes and rants every morning after the overnight builds, in which case he probably needs some serious behaviour modification.

Incidentally I believe it is possible to merge too frequently for other reasons, including the overhead involved with reviewing code. Maybe we should start another thread?

David Clayworth
Friday, April 04, 2003

*  Recent Topics

*  Fog Creek Home