top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

SVN: File size different downloaded compared to uploaded

+1 vote
472 views

When downloading files from the SVN bash (.sh) files are always a little bit bigger than the original committed file.

This seem to only be relevant to bash scripts as far as I can see until now. Ziped files are not affected it seems.

Using notepad++ in windows to compare the files, notepad++ informs that the files are a match. Though doing a MD5sum shows different MD5 hash.

Afraid that it might give effects on finished applications built from the SVN repo, as well as maybe corruption in files.

posted Oct 6, 2013 by Dewang Chaudhary

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+1 vote

You probably have an autoprops setting that sets the svn:eol-style property to "native" on .sh files, creating them with Unix end-of-line markers and retrieving them on Windows, where the end-of-line sequence is two bytes, not one.

answer Oct 6, 2013 by Deepankar Dubey
What would be the recommended solution to this? I assume there is a way around this to let clients handle this? Because when using googlecode the problem wasn't there, but now when using a self ran debian server there is an issue.
commented Oct 6, 2013 by anonymous
+1 vote

Do you have svn:eol-style set? If so, what is its value?

You mentioned Notepad++, which is Windows-only. On *NIX, the default EOL marker is n (LF), while on Windows its CRLF (rn). If svn:eol-style is set to native, when you check out on Windows the EOLs will be CRLF, and when you check out on *NIX, itll be LF - a difference of one byte per line. Visually, theres no difference. But there will be a checksum difference.

In Notepad++, turn on Show Whitespace Characters (I forget the exact wording, and am not in front of Windows at the moment). Do the same on a *NIX machine and your text editor of choice there. You should see a difference there.

answer Oct 6, 2013 by Luv Kumar
Similar Questions
0 votes
unversioned properties on SVN and size limitations?

Is there a limitation in size on the property value that can be set? Any scalability traps to be aware of (i.e. non-linear increase in time due to increase in size of the property value)? I tried a 4Mb property, seems to work fine...

+2 votes
size of .svn/pristine directory

I noticed that the size of the .svn/pristine directory can get huge over time (several times the expected size). A "svn cleanup" solves the problem, but

  1. this isn't documented (I'm wondering how many users know that);
  2. this isn't automatic.

About (2), svn could warn the user when a cleanup could be needed. I don't know what is the best solution.

+1 vote
SVN Add .xml file works fine on ubuntu but not on fedora?

I am using Fedora 20, subversion 1.8.5-2. In ~/.subversion/config I have

[miscellany]
enable-auto-props = yes

[auto-props]
*.xml = svn:eol-style=native; svn:keywords=Author Date Id Revision

When I do 

svn add my.xml
svn: E200009: Can't set 'svn:eol-style': file '/data/mysvn/trunk/my.xml' has binary mime type property

But with Ubuntu 12.10/subversion 1.7.5-1 svn add my.xml works just fine.

Any idea why the behavior is different?

+1 vote
SVN: Second commit is failing if space is in file name or file path

We are using Subversion (SVN 1.6.12-r955802).

Since the Apache version 2.2.24 has some security issues (multi-site security issue), we have moved to Apache version 2.2.25. But this updated version has the second commit issue. Issue details are given below.

"The issue with Apache 2.2.25 is when you have 'space' in folder name / file name. The first commit of these files / folders (with space in the name) is successful. We are facing issue only when subsequent commit is happening. We are using Tortoise SVN as client"

...