Saptarshi Purkayastha, an OpenMRS GSoC student this year, wrote mini java script and submitted a patch for adding the OpenMRS license to all of our java files. This was long overdue and was much appreciated, thanks Saptarshi!

Submitting this to trunk was no trouble at all, all things went as normal. However, when merging from trunk to other branches, I kept running into problems. All files that received the new license were showing as conflicts, even though there were no other changes. I had to manually copy the license from the old file to merged file. NOT fun. I did this manually when I was merging to the report-api-refactoring branch because it was late and I didn’t want to look up the “right” way to fix it.

Well, I think I found the reason.  Java file handlers don’t do prepending very well.  The script that Saptarshi wrote creates a new file with the license code, and then appends the old file contents.  The java newLine() method used in the java script to append that old file contents apparently uses a different newline character than the default for unix/windows.

This minor little difference caused two problems: 1) merging produced conflicts and 2) when comparing versions or showing annotations it showed that I had changed all lines when in fact I had just added the license header.

The fix for problem 1 above was to merge from trunk with the ignore-eol-style flag set:

svn merge -x––ignore-eol-style -r3684:3685 /home/ben/workspace/openmrs-api-refactoring

Note: I merged from trunk up to version 3684 first using the Subclipse svn gui (3685 was the revision with the license patch).  I ran the above at the command line to get a nice clean successful merge.  I was then able to merge from 3685 to HEAD using subclipse again.

I can’t really tell if this fixed problem 2 as well because I can’t remember which files this was happening to before.  The few files I queried were only showing me as having changed the first few license lines, so it appears to have solved it.

This is in the openmrs category tagged as , ,


5 Responses

  1. Saptarshi Says:

    I actually thought newLine() gave the default UTF-8 character for a new line and hence used it instead of “\n” in the string… Wondering how else it works ??

  2. Ben Says:

    Windows actually uses /r/n or similar, which would cause the discrepancy. I’ve been finding other non-conflicting conflicts when merging code that was committed on windows (I’m working in Ubuntu). I think from now on I’m going to have to merge from the command line so that I can use the –ignore-eol-style. :-/

  3. Saptarshi Says:

    I think its best to do it this way:

    public static String newline = System.getProperty(“line.separator”);

    I’ve learnt a useful lesson this way… But sorry for the trouble it caused you!!

  4. Ben Says:

    Fair point, but that wouldn’t have helped here. The problem is that “line.separator” on my machine still would have been the unix-style “/n” instead of the windows-style “/r/n”. When committed to svn, subversion sees the old files as:
    and the new files as:

    SVN sees this and thinks they are different unless you use –ignore-eol-style in your merge. :-/

    Chase recently committed an svn-property to have svn control the eol-style. That should help prevent things like this from happening…provided that we keep putting that property on all pages!

  5. The eflow blog » Fixing SVN Inconsistent Newlines Says:

    […] spoken previously about the travails of having a developer community that uses both Windows and Unix-based machines: […]

Leave a Comment

Your comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.