Mixing line delimiters destroys change history
Hi folks,
I'm seeing some strange behaviour after merging my work with a colleague's. As best I can tell, RTC (3.0.1) does not properly handle changesets with different line terminators. For example, I develop on Linux (LF) whereas some colleagues develop on Windows (CRLF). Recently we were each working on changesets affecting the same files. After I accepted my colleagues changes and merged with my own, the file comparison shows _every line_ as changed. Needless to say this makes the actual work of merging extremely frustrating and error prone. Additionally, I fear the change history is going to have an incomprehensible gap, baffling future maintainers. Has anyone else noticed this? Is this expected, or am I doing something wrong? /mike. |
5 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Sep 22 '11, 12:21 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The "Line Delimiter" property of a file controls how line delimiters are
handled for that file. I'm guessing that you have "Platform" set, which says to use the Line Delimiter convention of the file system you are using. So you have at least a couple of choices: - Pick one of the constant line endings (e.g. "LF"). Then all users will see the that line ending, no matter what machine they are loading the files onto. - Turn "ignore white space" on when you do the diff/merge. Cheers, Geoff On 9/21/2011 6:23 PM, mikereid wrote: Hi folks, |
So you have at least a couple of choices: Aha, I was unaware of the 'ignore white space' option. You have no idea how many headaches you just saved me. It slightly bothers me that internally the changesets are all screwy (as evidenced by the fact that the web UI still shows every line as changed). I guess this would be fixed by changing the line-ending property on the affected files. However it seems to me this is a bit backwards, or at least the default of 'platform' is not ideal. You almost never want to track changes in line endings as part of a file's change history, hence it seems the default should be to use one of the constant line-endings. I think the way Git handles this is instructive. Internally, they use a consistent line ending; AFAIK there is no way to change that. What users can control however is what happens with line endings during checkout -- mainly to play nice with editors or other tools that can't handle both types of line-endings. This keeps the change history clean and generally makes things "just work". Anyhow I can live with telling the Eclipse diff view to ignore whitespace. Many thanks, /mike. |
Choosing 'Platform' as your line delimiter should make it do what you want. It will convert the local file to the platform's default line delimiter and you wouldn't have problems with whitespace when comparing files.
I've never had an issue with my team and we work on different platforms (Windows & Linux). If you are setting it to 'Platform' and it's giving you whitespace differences, I think you should open a work item. |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Sep 24 '11, 1:24 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Interesting ... projects I've worked on have the same problem with line
endings reported by Mike. In particular, when a file has PLATFORM line termination, when I use the default Eclipse compare tool, a version checked in from a Windows box will have Windows line endings, while a version checked in from a Unix box will have Unix line endings, and I have to use "ignore white space" to get a useful comparison between those two versions. I had assumed that was the expected behavior ... if it is not, then one of us should file a defect on it. Cheers, Geoff On 9/23/2011 12:38 PM, tmok wrote: Choosing 'Platform' as your line delimiter should make it do what you |
Choosing 'Platform' as your line delimiter should make it do what you want. It will convert the local file to the platform's default line delimiter and you wouldn't have problems with whitespace when comparing files. I'm wondering what exactly this "Platform" setting is doing. In particular, as a Subversionista, I would be interested how it compares to the svn:eol-style property. For the record, I have also noticed changes to line endings, but they didn't cause the according line to be marked as changed, so just using different systems is not the only cause, as Geoff also says. What I'd look at is the general mime-type, because things like line-endings first require that the file is recognized as text in the first place. That said, just turning on "ignore whitespace" is not an option, since that means you don't see if you screwed up e.g. in the tabs vs. spaces area or indention in general. Not looking at your whitespace is only possible if you have a 100% coherent set of sources and the according coding rules and editor settings. We don't have this here. Cheers! Uli |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.