Living On The Edge - Automated Merging (Part 1)
An advanced branching topic that comes up every now and again is the topic of fully automating merges. By "fully automating", I mean taking the human out of the resolve process entirely for any changes that doesn't require an interactive resolve. A changelist is submitted by a human on one branch, and that submit initiates one or more automated integrate/resolve/submit operations to one or more target branches along a predefined merge pathway. The defined pathway that reflects your current branching strategy.
Eliminating humans from the process seems like a bold step. And indeed it is! Perforce's merging algorithms are a "best guess", based on what I call "text diff-chunk based logic." It's a tremendous value of Perforce that it does this so well, but there's only just so far that it can take you. Perforce doesn't try to understand the semantics of the C++ or Java or Perl code you're writing, and it's entirely possible that its best guess (the resolve result) won't be what you want. Such merge errors might only be detected at compile time. The worst case scenario is that you introduce a "semantic merge" problem, where the result of an automated merge is incorrect, but compiles OK and sneaks past testing, possibly even surviving long enough to be a customer-visible bug. Eek!
Adding insult to injury, because they can escape detection longer, semantic merge problems are harder to fix later, since the change is no longer fresh in the mind of the developer who originated the change. (It's usually best to merge changes soon after there made, ideally by the developer who originated the change if that's practical).
The Risk of Automated Merging
Maybe you're thinking, "This is too risky! Why would anyone ever do this?" Visions of train wrecks pop in your head!
But there are indeed reasons to do it! (To consider automated merging, not to wreck a train). If you're interested, stay tuned for more! To be continued ...
Continued in Living on the Edge - Automated Merging (Part 2).