I'm trying to merge from trunk to my private branch (branches/proto/v4) using svnmerge.py, and it's failing with the following error: svn: File 'libs\wave\samples\waveidl\idllexer\idl.re' has inconsistent newlines svn: Inconsistent line ending style Does anybody know how I can work around this? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
If it's listed as a text file, but the line endings don't match the platform convension then you will get that error: typically if you edit under Windows and then try and commit under Linux or something. Try using your favourite editor or dos2unix or similar to clean up the line ending so they match the platform convention, and then try to commit again. HTH, John.
John Maddock wrote:
All I'm trying to do is merge from trunk. I shouldn't have to edit files by hand, IMO. I worked around this a different way. I copied the file from trunk and checked it into my branch. Then I used the -M switch to tell svnmerge.py not to merge any of the changes to this file. After that, I was able to do a regular svnmerge.py. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
All I'm trying to do is merge from trunk. I shouldn't have to edit files by hand, IMO.
Sure, but somehow you've ended up with mixed \n and \r\n line endings, and that's really not something you should be checking in IMO. As for why the file ended up that way, that's a whole other issue... John.
John Maddock wrote:
Sure, but this is not a file I've edited locally. And I can't imagine my svn client would do that to line endings.
As for why the file ended up that way, that's a whole other issue...
<shrug> -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, 5 Aug 2008, John Maddock wrote:
Official or not, Boost effectively endorses \n as the one true line ending; the release files have names like boost_1_35_0.7z and boost_1_35_0.tar.bz2, no line-ending choice available. SVN should not act like FTP with text and binary modes, munging bytes as they flow. It should maintain bytewise-exact copies of what the user intended, possibly with commit hooks to reject bad line endings. My $0.02. - Daniel P.S. Once you have exact copies, you can add a layer to cryptohash each revision, checking for corruption in the system... Each patch would contain the hash of the tree it applies to. Then you could use those cryptohashes for distributed revision control... ;)
AMDG dherring@ll.mit.edu wrote:
The .zip files have \r\n line endings.
Have you read http://svn.boost.org/trac/boost/wiki/BoostSubversion#MIMETypesandEnd-Of-Line... In Christ, Steven Watanabe
On Tue, 5 Aug 2008, Steven Watanabe wrote:
Beman pointed out the 7z files do as well. My bad. I entered a trac issue; the downloads page on the website should probably embellish "Platform independent" with "(\r\n line endings)" and "(\n line endings)".
I've looked at it before and think its a mess. Why can't SVN store this info be on the server under central administration? Don't these settings affect all SVN projects a developer works on, not just boost? Configure a few Windows editors and compilers to use the plain \n, and this can all go away... - Daniel
dherring@ll.mit.edu wrote:
Unfortunately we can't change that. Those are fixed fields in the SF file publishing system. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
participants (6)
-
Beman Dawes -
dherring＠ll.mit.edu -
Eric Niebler -
John Maddock -
Rene Rivera -
Steven Watanabe