5

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.

Jan Zich
  • 14,993
  • 18
  • 61
  • 73
  • What type of file is it? Does it have any svn:props set? What does an svn diff show if you compare your branch version to the trunk version? – Ryann Graham Feb 26 '09 at 20:29
  • I did a diff on one file (a csproj file) and I got the expected result. But when I ran the svn merge on the entire tree, the "df" command showed the entire file as conflicted. – Jan Zich Feb 26 '09 at 21:22
  • All your files are conflicting or only a few of them? Were conflicting files changed on both branches after creating the branch or only on one? How far apart from each other (in terms of lines) were changes made on different branches? – Tomek Szpakowicz Feb 26 '09 at 22:53

5 Answers5

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.

Mark
  • 28,783
  • 8
  • 63
  • 92
2

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).

Jan Zich
  • 14,993
  • 18
  • 61
  • 73
0

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

Ben S
  • 68,394
  • 30
  • 171
  • 212
  • I’ve tried it, but with the same result. I was also puzzled by the interface and so I opted for the lowest common denominator: a command line client. I’ll try it one more time and provide an update. – Jan Zich Feb 26 '09 at 20:14
0

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.

Pete
  • 17,885
  • 4
  • 32
  • 30
0

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.

Stefan
  • 43,293
  • 10
  • 75
  • 117