svn: Inconsistent line ending style

[Gregg Tavares (社用)]

I'm running into this error trying to check in some files.

$ gcl upload somechange

Got error status from 'svn cat somefolder/somefile.c'

Typing

$ svn cat somefolder/somefile.c

..bla.bla.bla

svn: Inconsistent line ending style

The file in question has consistent line endings. I've run dos2unix on it. I've checked it with 

$ hexdump -v -e '"x" 1/1 "%02x "' somefolder/somefile.c | grep 0d

Which shows no matches vs 0a which shows all the line endings.

The intertubes say check my svn properties

http://stackoverflow.com/questions/917392/how-should-i-fix-svn-inconsistent-line-ending-style

There is only one property on that file, svn:eol-style

Removing it doesn't help. Adding it back doesn't help

There are no svn properties on any folders at or above that file

I've checked my ~/.subversion/config, it's got consistent line endings and is the appropriate version from the chrome repo.

I've deleted the entire tree, gclient synced and reapplied the changes

No luck

Anyone know where the problem is hiding?

[Pam Greene]

Dunno, but here are some troubleshooting steps that come to mind:

Make sure the file is encoded as UTF-8 (or ASCII).

Revert your changes to that file and verify its original line endings. It shouldn't be able to have inconsistent endings with svn:eol-style set, but it's an easy thing to check.

Revert your changes to that file, make a 1-character change, and try uploading it.

Examine the full 'svn diff' in hexdump and see if there's any nonprinting character in it at all.

- Pam

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

-- 

Google Germany GmbH Dienerstr. 12 80331 München

AG Hamburg, HRB 86891  Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Katherine Stephens

Tax ID: 48/725/00206  VAT ID: DE813741370

[Gregg Tavares (社用)]

On Fri, Nov 16, 2012 at 7:06 PM, Pam Greene <p...@chromium.org> wrote:

Dunno, but here are some troubleshooting steps that come to mind:

Make sure the file is encoded as UTF-8 (or ASCII).

Revert your changes to that file and verify its original line endings. It shouldn't be able to have inconsistent endings with svn:eol-style set, but it's an easy thing to check.

Revert your changes to that file, make a 1-character change, and try uploading it.

Examine the full 'svn diff' in hexdump and see if there's any nonprinting character in it at all.

Hbono took a look and claims the issue is svn is complaining about the file in the repo not the edited file. A solution might be to delete the file from the repo (assuming it doesn't still complain) and then add it back in as a new file. He's curious how it go into that state in the first place. Maybe we updated to new svn that's stricter than before? They're 3rd party files.

Anyway, I'm just going to use git. I don't know why I thought I needed to use svn for this particular thing.

Thank you for the suggestions.

[Pam Greene]

I've seen that happen before. (Hence my second suggestion, although I'm not positive it would show up in the local checkout.) So I don't think it's due to a more recent version of svn, unless this file hasn't been touched in a long time. But I also don't know how it could happen.

- Pam