When trying to merge from our trunk to a branch I was getting these errors:

svn: File ‘/tmp/svnkitmerge42139.tmp/.diff.192.tmp’ has inconsistent newlines
svn: File ‘/tmp/svnkitmerge42139.tmp/.diff.192.tmp’ has inconsistent newlines


svn: File ‘/tmp/tmp’ has inconsistent newlines svn: Inconsistent line ending style
svn: Error reading spooled REPORT request response

svn: Generic IO error
svn: Generic IO error

Here are the steps I did to get around this and still merge from trunk to the branch:

  1. Check out a fresh copy of the branch.
  2. Merge the branch to the latest, skipping over the revision that did the newline changes (5893 in my case). You might have to do two merges for this: previous merge point to 5892, then one from 5894 to HEAD.
  3. Run the fix_newlines.sh script.
  4. Commit the branch.

Note: If you have changes on another checked out copy, an “svn update” won’t work on that one. You will have to apply a patch of the changes to the freshly checked out/merged copy.

This is in the openmrs category tagged as , ,

Add a comment »

I had a lot of trouble recently merging a renamed branch back into trunk. I ended up having to resort to the command line to get the exact parameter setup that I wanted. Subclipse didn’t quite cut it, unfortunately.

To set the stage:

  1. All changes on trunk have been merged to the branch (complex-obs) and committed
  2. The checked out trunk copy is up-to-date

I created a patch file comparing trunk to the branch:

svn diff –old /home/ben/workspace/openmrs-trunk-clean –new http://svn.openmrs.org/openmrs/branches/complex-obs > /home/ben/openmrs/patches/complexobs.diff

I then applied that patch file to my local trunk copy:

patch -p0 < /home/ben/openmrs/patches/complexobs.diff

This should only be used if you plan on closing the branch. Subversion isn’t able to keep track of any ancestry this way, so future merges would be harder.

Note: Diff files don’t handle binary files. You will need to move those yourself. I suggest comparing the patched trunk with your branch to make sure everything is the same. (In eclipse, select the root of both projects, then right click–>compare with–>each other)

This is in the babble, openmrs category tagged as , ,

Add a comment »

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 http://svn.openmrs.org/openmrs/trunk /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 , ,