What can cause SVN Update to merge incorrectly?

Question

I got an email a few days ago from someone who was having trouble building a Delphi project I have on Google Code. The project file and one of the DFM files were munged after he updated with some changes I had checked in. We talked back and forth a bit, and traced it down to what he said was SVN throwing in extra stuff. He deleted the files and ran Update again and it worked fine.

I've never seen this problem before, and I wasn't able to reproduce or verify any of it at my end. There weren't any update conflicts with other users, since I'm the only one with write access to the repository. So I'm wondering what could have caused this. Is this a known issue for SVN? Is there a way to keep it from happening?

Answer 1

Suppose he or his local system managed to mangle the two files.

Then suppose he updates and finds things not working. After some finger-pointing he deletes the files with, ahem, local mods, runs update, and gee ... the right files!

Entia non sunt multiplicanda praeter necessitatem.

While it is always possible that a strange syntax error is a compiler bug and a corrupted file is an svn bug, there are usually more prosaic reasons, and we have it on William of Ockham's authority that the simpler explanation is usually the correct one.

Answer 2

If the DFM file was treated by Subversion as text, assuming the user had local changes, it will attempt a merge. Where there are conflicts and Subversion can't resolve them, it will add extra detail to help you manually resolve the conflicts, you will see text like <<<<<<< .mine which of course will bork in Delphi. It could also be that Subversion did a merge automatically, which didn't conflict, but lead to a corrupt DFM file.

The reason why you didn't see the problem was probably because you didn't have local changes, so no merge was necessary. Deleting or reverting the files resets the working copy back to BASE so any update won't need to do a merge.

One solution: If you have text files which should not be merged by Subversion, then set the svn:mime-type to an appropriate non-text value, and it will treat it as binary, and won't attempt a merge. You will be required to manually fix the problem. Incidentally, this is also a good tip if you need to store sensitive text files in Subversion and don't want diffs showing the content :)

Answer 3

Did the "munged" files contain "mine" or "theirs" text?

If so he probably mucked up his conflict resolution and ended up committing the theirs or mine rev inadvertently.

Or it's entirely possible that the merge thought it could auto-merge changes because they were in "unrelated" parts of the file, but for SVN (or any naive auto-merge process) "unrelated" simply means in lines of the files that don't/didn't overlap.

"Naive" auto-merge knows nothing about any structure internal to the file so may easily merge changes that it believes are unrelated when in fact the changes have adverse side effects on each other. Without knowing precisely the nature of the "munging" it's hard to say for sure, although in this case the reference to "extra stuff" suggests that inadvertent commital of "mine" or "theirs" revisions seems most likely.

Answer 4

Which Delphi version? Older Delphi versions had bugs in which sometimes text DFM files became binary.

Files suddenly becoming binary kill any source control system.

--jeroen

Answer 5

Are you working on multiple platforms? Are you using editors that assume Unix lineendings (like some cygwin tools?)

If so, check if you configured the eol-style property properly.

Answer 6

I was perform a SVN update and SVN was mucking up the DFM files with <<<<<<<<.mine, which I'd never seen before. I had to manually delete those modifications before Delphi would allow me to open the project.