Jeremy, you've stolen my quote  ;-)

Actually, whenever I'm asked how do I deal with merge conflicts, the answer is always, "checkin before the other guy".

That's why when anyone ever asks, "is anyone integrating", my answer is always, "yes, me"

But, if you are the one doing merge conflict resolution, it means that your code can always trump the conflicting code

Hehe just revert the other ones changes, if it happens you are not fast enough ;)

"But, if you are the one doing merge conflict resolution, it means that your code can always trump the conflicting code"

Yes, but it also means that you are the one having to deal with a larger delta.

In the last few environments in which I've worked, we've even gone as far as to describe committing first as "winning". The desire to "win" by committing first needs to be tempered with good practices, a retained requirement to meet all pre-commit criteria, etc., of course, but I have found that encouraging people to "win" creates a healthy feeling of competition where people end up competing to see who can do better work decomposition (so they can commit sooner) which often effectively translates into competing to see who can produce better-designed code. It really can be a "win" for everyone, if guided with a degree of care to keep things balanced (I want everyone to compete in a healthy way, not to rush, for example.)

And that is one big pink elephant in the room no one seems to talk about in the alt.net.

Um...

Why is the elephant pink?

Seriously, though. I don't know that I believe in "healthy competition" within a single team anymore. It may be fun for 2 guys to play with each other over a particular issue like this, but an ongoing behavior of "gotcha" is detrimental to the overall team, in my experience.

ROFL -

Max's First Rule of CI Club...Don't Talk About Merging...Second rule of CI Club - DON'T TALK ABOUT MERGING!

@David - then I think you missed my points about  keeping things "tempered with good practices, a retained requirement to meet all pre-commit criteria" and competing "in a healthy way". Obviously, even then this isn't blindly applicable to all personality types and/or in all environments, but I would hope that I need not make that explicit given that ANYTHING to do with ANY software development process is highly dependent on the environment under consideration.

On a random but related note, anyone working in an environment where they think that this _wouldn't_ work should probably take a long, hard look at the people and processes around them. I suspect you'd find that there are much larger problems lurking. As should seem obvious in hindsight, the possibility of healthy competition in your environment is almost entirely dependent on the existing health of your environment.

Since the first one inevitably irritated people, let's go for rule #2 & #3: 2.) Check in as often

Seeing that DJ Miller is spinning up some amusing-but-true laws of continuous integration , I'm gonna

Since the first one inevitably irritated people, let's go for rule #2 & #3: 2.) Check in as often

Seeing that DJ Miller is spinning up some amusing-but-true laws of continuous integration , I'm gonna

Since the first one inevitably irritated people, let's go for rule #2 & #3: 2.) Check in as often

Seeing that DJ Miller is spinning up some amusing-but-true laws of continuous integration , I'm gonna

Oh so true...and a daily favorite of mine ;)  I haven't seen a merge tool in months...good luck sucka's

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #185

Pingback from  Dew Drop - September 23, 2008 | Alvin Ashcraft's Morning Dew

Pingback from  Jeremy’s Other Laws of Continuous Integration - taccato! trend tracker, cool hunting, new business ideas

Pingback from  Laribee’s Final Law of Continuous Integration - taccato! trend tracker, cool hunting, new business ideas

Podcast #4 - Continuous Integration and FireBug

Podcast #4 - Continuous Integration and FireBug