Comments on: Merging Apparently Non-Conflicting Conflicts with SVN http://blog.eflow.org/archives/45 Insert some amazingly witty tagline here Fri, 11 Jun 2010 13:45:56 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: The eflow blog » Fixing SVN Inconsistent Newlines http://blog.eflow.org/archives/45/comment-page-1#comment-169 The eflow blog » Fixing SVN Inconsistent Newlines Mon, 03 Nov 2008 15:21:34 +0000 http://blog.eflow.org/?p=45#comment-169 [...] spoken previously about the travails of having a developer community that uses both Windows and Unix-based machines: [...] [...] spoken previously about the travails of having a developer community that uses both Windows and Unix-based machines: [...]

]]> By: Ben http://blog.eflow.org/archives/45/comment-page-1#comment-35 Ben Fri, 09 May 2008 20:45:19 +0000 http://blog.eflow.org/?p=45#comment-35 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: .........../r/n ........../r/n and the new files as: .........../n .........../n 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! 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:
………../r/n
………./r/n
and the new files as:
………../n
………../n

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!

]]> By: Saptarshi http://blog.eflow.org/archives/45/comment-page-1#comment-34 Saptarshi Fri, 09 May 2008 20:38:11 +0000 http://blog.eflow.org/?p=45#comment-34 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!! 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!!

]]> By: Ben http://blog.eflow.org/archives/45/comment-page-1#comment-20 Ben Tue, 29 Apr 2008 12:03:04 +0000 http://blog.eflow.org/?p=45#comment-20 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. :-/ 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. :-/

]]> By: Saptarshi http://blog.eflow.org/archives/45/comment-page-1#comment-19 Saptarshi Tue, 29 Apr 2008 07:12:28 +0000 http://blog.eflow.org/?p=45#comment-19 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 ?? 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 ??

]]>