5
Vote

SVN Commit corrupts binaries

description

I started this Work Item here (http://codeplex.codeplex.com/WorkItem/View.aspx?WorkItemId=21733), sorry for the cross-post. This is probably where it will get attention and a fix.

When committing to CodePlex using TortoiseSVN, the 3rd party libraries and NAnt.exe files get corrupted. If you attempt to do an SVN CheckOut to a new folder, your binaries are invalid.

For example, compare the committed StructureMap.dll (http://dbfriend.codeplex.com/SourceControl/changeset/view/785#48994) with the one I'm attaching to this case.

file attachments

comments

cartoixa wrote Mar 25, 2009 at 4:39 PM

It seems like I posted in the wrong project too (http://codeplex.codeplex.com/WorkItem/View.aspx?WorkItemId=21720).

Same thing happened to me with my images. If I replace the corrupted images with new (and correct) ones, I get the following error in TortoiseSVN :

Error: Commit failed (details follow):
Error: While preparing 'S:\Work\src\Sdml\Dsl\Resources\MultipleAssociation.bmp' for commit
Error: Inconsistent line ending style

Mime type for this file is set to application/octet-stream...

brettveenstra wrote Mar 26, 2009 at 12:20 PM

I was able to commit using the Teamprise client last night and the binaries remained intact for an SVN Checkout, but this is not a sustainable workaround solution. Totally different mindset to SCM.

cartoixa wrote Mar 27, 2009 at 1:15 PM

I checked out using the Teamprise client, and my images were correct. It seems like my problem lies only in the checkout via TortoiseSVN... Unrelated ?

cartoixa wrote Jun 12, 2009 at 8:16 AM

Hello, anybody out there ?

cartoixa wrote Jun 22, 2009 at 8:00 AM

I just realized that all my corrupt binary files seem to have the SVN svn:eol-style property set (rather inconsistently to native, or CRLF). svn:keywords and sn:mergeinfo properties are also set.

I am absolutely very positive about the fact that I did not set these properties locally.

jwanagel wrote Jun 25, 2009 at 11:08 PM

I've done some investigation into this and confirmed that having an svn:eol-style property set on a binary file will screw up the checkout. The correct data is being sent down, but when TortoiseSVN sees the property it modifies the file. So the question is how is it getting set?

cartoixa wrote Jun 26, 2009 at 8:09 AM

Unfortunately, "Show log" is unavailable via svnbridge (makes TortoiseSVN crash right now. When it did not, I remember having only one entry in the log, whatever the history of the file). And I can't seem to be able to see these properties via the online browser.

If you can get more information on your side, here is a link to an impacted file : https://salamanca.svn.codeplex.com/svn/trunk/src/Sdml/Dsl/Resources/File.ico.

cartoixa wrote Jun 26, 2009 at 1:38 PM

I just removed the incriminated properties from by binary files using TortoiseSVN, then committed the whole thing. Checked out in another folder : svn:eol-style and friends were back and files were corrupt...

brettporter wrote May 18, 2010 at 3:43 PM

Same problem here checking in test DLLs. The properties are definitely not set, and are not in the subversion config autoprops, but keep turning up. Deleting them has no effect (it works on the local checkout, but a new checkout sees them come back).

fool wrote Aug 14, 2010 at 1:11 PM

I'm seeing this problem too and didn't realise I was supposed to post here(?). http://codeplex.codeplex.com/Thread/View.aspx?ThreadId=219806.

I just did yet another test and can confirm that 'svn checkout' or 'svn export' mangle a few of my PNG files. Specifically, the files that get mangled have both svn:mime-type=image/png and svn:eol-style=native (checked with svn proplist on the commandline). I never added svn:eol-style=native in the first place, and attempting to delete this property is an exercise in futility - it seems to be deleted but then comes back on the next checkout / export!?

The handful of affected files are:

Virtu\Xna\Background.png
Virtu\Xna\AppThumbnail.png
Virtu\Silverlight\Phone\Background.png
Virtu\Silverlight\Phone\AppIcon.png

This is making it very difficult to work reliably with svn and codeplex.

Sign in to add a comment or to set email notifications