SVN messes with my files with jibberish data, why?

Sometimes, I find myself in a situation where valid files are made invalid by doubling the contents, placing ======= in the middle, <<<<<<< .mine at the beginning and <<<<<<< .r1276 at the end. This results in unbuildable projects:

<<<<<<< .mine
using System;
using System.Data;

namespace MyNamespace
{
     class Xyz
     //... a lot more code ...
}=======
using System;
using System.Data;

namespace MyNamespace
{
     class Xyz
     //... a lot more code ...
}
>>>>>>> .r1276

It seems to want to say "the first part is mine the second part belongs revision 1276", but why does it do this and more importantly, how do I prevent it? I use AnkhSVN and Visual SVN / Tortoise from Visual Studio. I probably clicked the wrong buttons, but wdon't know which I did and would gladly hear from someone more knowledgeable with SVN how I managed to get my files to messed up and what to do to prevent i开发者_运维问答t next time around.

---

You have merging conflicts that need to be resolved. TortoiseSVN will show these files in a conflicted state, with the "Gibberish" being the way that SVN tracks the attempted merge information.

Do not alter the files manually. Use TortoiseSVN "Resolve conflicts" and the UI it provides to resolve these conflicts.

These conflicts arise after two developers have edited them and are trying to check-in their changes and the two files cannot be automatically merged.

---

@Dave White gave the definitive answer (+1), and I have an additional tip, for what it's worth.... Prior to doing a get, I like to review my local changes to see if there is anything that I really should revert. I program in Delphi, so I typically have lots of .bdsproj and .res files that have silly modifications such as autoinc revisions, minor path differences, etc.. (Our "official" revision numbers come from our automated build tool, so the local ones are moot). And of course, these are lines in the file that would directly conflict with any other updates caused by the automated build, since I did my last get. By reverting my unimportant local changes prior to the "get" (svn update), I avoid dozens of senseless .mine problems.