SVN marks entire files as conflicted

Question

I'm new to SVN. After working on a branch for a day or so, I attempted to merge changes from the trunk to the branch:

svn merge svn://server/trunk

The problem is that whenever SVN encounters a conflicting file, it's not able to recognize line by line changes and marks the entire line as conflicted. I experimented with several other SVN clients and also tried to toggle the end-line and white-space options without any progress. What am I doing wrong? I think this is the simplest possible merge case, so I would expect this to work with the most default Subversion settings, any client and in any SVN version. Is it some known beginner's catch?

Client: 1.5.5 (SlikSvn:tag/1.5.5@34877) WIN32

Server: 1.4.6 (r28521), Windows

Edit

Based on the suggestions in comments and answers below, I did more investigation:

1. The problematic files are UTF8.

2. They don't have any SVN properties.

3. The "svn diff" command correctly identifies the differences.

Answer 1

Merging in SVN is... well, it's merging in SVN. :-)

You'll have to resolve the conflict in order to merge. Other VCS tools like Bazaar (Wikipedia) or git (Wikipedia) can handle merging better most of the time due to the way that they work, having more than just the working copy stored locally. I'd recommend looking into both in the long run; if you know Subversion, Bazaar (often called bzr after it's command line program's name) may be a good option for you. I have used both, and like git, but love bzr. I even use bzr to interface with Subversion repositories that I have to work with (via the bzr-svn plugin). Bazaar is also more cross-platform than git; bzr works very well on Windows, if you have to use such an operating system. ;-)

ETA: As an aside, I used to use Subversion. The very reason I stopped was that I very much did not like its merging as that is an activity that I do regularly.

ETA2: To clarify, the only answer is to resolve the conflict. That is what you do in svn when you have a conflict. My suggestion to look into other VCSes was so that the OP can take a look and perhaps find something that will help them in the future; preferably interoperable with their current situation. I know that Bazaar does this, and I am pretty sure that git does this, though the OP since revealed that Windows is the system in use, so Bazaar would be the likely option to look into for the future. 'twasn't a "You should move to X, and now" type thing. Apologies if I was misunuderstood there. Also, Bazaar is command-line compatable (bzr co and bzr ci and bzr log, etc, making the interface very comfortable for people who know Subversion).

Answer 2

Have you tried using TortoiseSVN? It come bundled with ToroiseMerge which I find to be a decent merging too.

Answer 3

I haven't used SVN a ton, and I've only used it through the eclipse plug in, but there might be some scenarios where you simply have to tell it which case to use (your local vs the remote file). merging a set of disjoint outgoing and incoming changes isn't usually a problem, but if a line conflicts with certain types of changes (in eclipse it marks the whole line/block as red) you may just need to accept one or the other since it will probably not merge further on its own.

Answer 4

Check the svn:mime-type property on your files. If there is such a property set and its value does not start with 'text/', then Subversion treats those files as binary and not text.

If your files are encoded in utf-16, Subversion will also treat those files as binary by default.

Answer 5

We had this issue recently and found that it was a problem with using a 1.4.x server and a 1.5.x client. Subversion 1.5 introduced more intelligent merging but you need the server and client to be running 1.5 to take advantage of this.

We found that specifying the range of revision numbers that we wanted to merge gave the expected results.

Answer 6

I've selected Mark's answer. This is just to summarize and provide more details. My problem is caused by the fact that we are using SVN 1.4 which does not support the more advanced 1.5 merging features. As indicated by the selected answer, I found that I have to use the following format of the SVN merge command (in case I want to propagate changes from trunk to my branch):

svn merge svn://dpr/branches/abc@REV svn://dpr/trunk@REV

I guess that my confusion was caused by the fact that the SVN book and the clients I was using were silently assuming that I was already running 1.5 and the examples and the default merging methods were using the new features. To be fair, the introduction to the Basic Merging section in the SVN books mentions it (which I noticed only when I resolved the issue).