A blog about software development, primarily in Java and about web applications.

Tuesday, April 29, 2008

Subversion: Inconsistent line ending style

We use Subversion and have people working on Unix, Windows, and Macs. This occasionally causes problems with newline characters. All of us use the same Subversion config file in our home directories so that svn:mime-type and svn:eol-style get set correctly for various file types, but I don't know a way of specifying the svn:eol-style for properties that Subversion lets you set on directories. We use both svn:externals and svn:ignore on our projects. I've just started to integrate FogBugz (the bug tracking system we use) with Subversion and this requires even more Subversion properties.

For the most part everyone uses Eclipse as their IDE and editor. A few people use Vim or Emacs in addition to Eclipse. I've always been able to solve these newline problems before this week. However, this week I Subversion wouldn't let me edit or even list the properties:

$ svn propedit svn:externals .
svn: Inconsistent line ending style

$ svn propget svn:externals .
svn: Inconsistent line ending style

$ svn propget svn:externals .
svn: Inconsistent line ending style

$ svn proplist .
Properties on '.':
bugtraq:label
bugtraq:url
svn: Inconsistent line ending style

Eclipse with its Subclipse plugin was able to show all of the properties. But didn't allow me to correct this so that I could work with the properties on our common Unix test and development servers.

I did find mailing list comments about this and some people recommended changing the Subversion files under the .svn directory. This is slightly tricky because of the format and apparent byte counts in the file.

An easier solution turned out to be the propdel command. I vaguely knew which property was causing the problem and just deleted it. After that the proplist, propget, and propedit commands all worked. To get back the value I just deleted, I used the svn diff -N . command to see the old value and just copy-pasted it back in with the svn propedit command.

I've generally found that working on Windows and with Eclipse and Subclipse, I still need to have the command-line version of Subversion installed to work around issues like this or help people debug issues they run into with Subversion. TortoiseSVN is also helpful some times. But I've found it's impossible to rely solely on Subclipse.

Just fyi...on my machine I have Subclipse, RapidSVN, TortoiseSVN, and the command-line SVN all installed. I rarely use RapidSVN, but occasionally I find useful as a repository browser.

No comments: