Menu
We've recently installed Visual Studio 2012, and I'm working on a brand new project in there with one other member of our team, using Team Foundation Server 2010 for source control. I recently noticed some of my files getting randomly mangled when I check in. Then noticed in the output window notifications about conflicts, which were automatically resolved!?
It turns out this is the default setting in Visual Studio 2012!
I found an article on MSDN detailing how to turn this setting off (http://msdn.microsoft.com/en-gb/library/vstudio/ms181432.aspx#automatic_options), but I'm curious if anyone knows why this potentially devastating setting would be on by default?
269
You can't "turn this off", because there is no other safe way to resolve the clash. The closest you can get to turning merging off is to disallow multiple checkouts (lock the file so that only one developer can work on it at a time).
Often, merge conflicts happen when people make different changes to the same line of the same file, or when one person edits a file and another person deletes the same file. You must resolve all merge conflicts before you can merge a pull request on GitHub.
When you pull or merge branches, Git will select the recursive strategy as default. The recursive strategy only can detect and do merges which involve renames, but cannot use detected copies. The ours option forces conflicted parts to be automatically resolved by favoring 'our' version.
Because it's the default in most other tools, and people coming to Team Foundation Server found it frustrating that they would have to explicitly tell the tool to automerge. More to the point, people didn't even find it obvious that they would have to explicitly tell the tool to automerge and complained about the sheer number of conflicts produced by merging branches, because in many tools, users aren't even told about a "merge conflict" until it can't be automerged. Thus it appears that Team Foundation Server failed to do a three-way merge properly.
Obviously, the correct default here is a judgement call. I didn't make it, but I support it.
I worry, though, that this change in defaults is exposing some issues in your merge workflow. Automerge can absolutely produce results that a human wouldn't produce, there's no question about that. But it's a well-established standard and generally considered safe, useful and generally correct.
If this is somehow "dangerous" then your process should catch that long before you check in. Hopefully you would have built locally and run a full test pass long before you check in and your continuous integration build would also catch these errors if you failed to do so.
If automerge produces incorrect output, you can always merge the file by hand. And, of course, you can also just turn the automerge option to "off".
192
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
