This is Part One in my introduction to the Eclipse Synchronize View
I'm not ashamed to admit it: my first time was terrifying.
It was a friday afternoon in late spring, and I was lazily fixing bugs while mostly thinking about what I'd do when I got off work. I wasn't even paying attention - I was just staring out the window when I decided to do a Get Latest. Then, from nowhere, was the Big Bad Merge.
It turns out that one of my coworkers had done a major refactor of our project, and we'd both been working on many of the same files. Automerge couldn't handle it - oh no, these changes were nasty and invasive - I resolved them all by hand, well into the night.
The state of version control has changed significantly since then - atomic transactions and bug tracking integration were unheard of then - but even with a version control tool like Team Foundation Server, many of us still have no idea what's coming at us when we do a Get Latest. Many of us have no idea when the Big Bad Merge might appear for us to fight again.
It's a scary thing to live in constant fear of conflicts. Many programmers have strategies for dealing with this unknown... most of them ineffective... Here are some of the coping mechanisms I've seen:
The "Real Programmer"
Many programmers, after their first few Big Bad Merges, develop a strange belief that merging is somehow a "real programmer's" sport. That their successful ability to merge widely disparate codebases is what separates them from those lower echelons of untalented hacks who use crutches like "automerge" to get the job done for them. The eschew tools - preferring to pore over every line of code, fixing even indentation and line breaks, than trust a tool to do the job for them.
Their tales of "that nasty conflict that took all day to resolve" are often accompanied by bragging about how they merged back in "the old days", presumably done on punch cards, uphill both ways in the snow.
This particular coping mechanism is very dangerous, as it's entirely psychological and doesn't actually get your conflicts resolved any quicker or more accurately. It often has the opposite effect, as these are the sorts of people who are prone to throw out their three way merge tools[1] in a fit of hubris.
You can identify the "Real Programmers" easily as they use obscure operating systems with an 80x24 green on black terminal, and drink black coffee (not because they like it, but because it puts hair on their chest.)
The "Edge Case"
Some programmers have had just one too many of those really hard merges and it's left them shell-shocked and resentful of ever having to do it again. They respond with a little insurance policy - a second copy of the source tree, isolated from the one they're working in, which they keep updated constantly so they know what conflicts are coming down the line.
Unfortunately, the line between "proactive" and "insane" gets blurred pretty quickly and eventually they're spending as much time looking at the changes you've made as they spend actually working. They get farther and farther away from the server's version and closer and closer to that Big Bad Merge they were trying so desperately to avoid. As they realize what's happening, they become increasingly nervous and erratic. They often become angry and will lash out you - after all, it's you that made those checkins, and put their working repository into a conflicted state. (Helpful hint: avoid the "Edge Cases" with an affinity for large caliber firearms.)
Eventually, these programmers will spend a panicked, sweaty afternoon getting their changes checked in and their work repository up to date, and they'll be productive again... at least until the next conflict.
You can identify the "Edge Cases" by their facial ticks, occasional psychosis and their desire to work for the Post Office or TSA.
The "Agilist"
Some programmers get smart, and decide to minimize the cases of the Big Bad Merge by developing a a "checkin early, checkin often" attitude[2]. Thinking - correctly - that if they track the latest version on the server and make small, incremental changes, they're never so out of sync that they have a really horrible merge.
Ultimately, anybody on a team who uses this style of development is rewarded with few conflicts that are kept small and manageable. This means those developers get an added bonus: they implicitly punish their Lazy, Annoying Coworker[3] by making them deal with the big bad merges.
The problem with this solution is that eventually your Lazy, Annoying Coworker is going to catch on and adopt this solution for himself[4]. There are few things worse than a programmer who's simultaneously lazy and annoying and checks in quickly. Soon the Lazy Annoying Coworker will be checking in before they bother to test what they just wrote - or worse, even bother to compile it. Suddenly builds fail due to missing quotes and poor use of semicolons.[5]
So what's a software hack to do? How does one cope with this constant unknown?
One makes it a known problem -- one gets better tools.
One uses the Eclipse Synchronize View, which I'll demonstrate in my next post.
- Shameless plug: SourceGear's excellent DiffMerge 3.0 will be available very soon.
- (I'm not entirely sure, but I suspect that the entire "Agile Methodology" sprung from a really long day of merging branches with CVS.)
- Not having a Lazy, Annoying Coworker is much like playing poker without a chump. As Amarillo Slim said: "Look around the table. If you don't see a sucker, get up, because you're the sucker."[6]
- Or start cleaning his handguns at work.
- (Being Lazy and Annoying, when you confront your Coworker with this, they'll merely shrug and make you deal with it yourself.)
- As I've mentioned previously, my coworkers are neither Lazy nor Annoying. I'm sure that you realize what this says about me.
