File size different downloaded compared to uploaded

2013-10-06 Thread Helge Rossvoll 
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.

Anyone with any idead?

Server =
OS: Debian
Kernel: 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
SVN: svn, version 1.6.17 (r1128011)
Apache: Apache/2.2.22 (Debian)
Transport mode: HTTP (not https)

Med vennlig hilsen
Helge Rossvoll
Seniorkonsulent, iTet AS, Mobil: 41 17 61 75
[cid:image001.png@01CEC2CA.A3B789E0]
[cid:image002.png@01CEC2CA.A3B789E0]
Denne meldingen (og eventuelle vedlegg) er bare ment for mottakeren, og kan 
inneholde fortrolige opplysninger eller annen privat informasjon.
Hvis du mottar denne ved en feil, vær så vennlig å varsle avsender og slett 
meldingen.
Har du behov for hjelp fra vårt kundesenter kontakt 
9...@itet.no eller ring 400 00 911.
iTet er sertifisert for ISO 9001 og ISO 14001 - Vi tar kvalitet og vårt 
miljøansvar på alvor.
[cid:image003.png@01CEC2CA.A3B789E0]

<><><>

Re: File size different downloaded compared to uploaded

2013-10-06 Thread Branko Čibej 
On 06.10.2013 10:33, Helge Rossvoll wrote:
>
> 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.
>
>  
>
> Anyone with any idead?
>

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.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: File size different downloaded compared to uploaded

2013-10-06 Thread Andy Levy 
On Sun, Oct 6, 2013 at 1:33 PM, Helge Rossvoll wrote:

> 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.
>
> ** **
>
> Anyone with any idead?
>
> ** **
>
> Server = 
>
> OS: Debian
>
> Kernel: 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
>
> SVN: svn, version 1.6.17 (r1128011)
>
> Apache: Apache/2.2.22 (Debian)
>
> Transport mode: HTTP (not https)
>
>
>
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 it's CRLF (\r\n). 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, it'll be LF - a difference of one byte per
line. Visually, there's 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.

RE: File size different downloaded compared to uploaded

2013-10-06 Thread Helge Rossvoll 
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.

Med vennlig hilsen
Helge Rossvoll


-Original Message-
From: Branko Čibej [mailto:br...@wandisco.com] 
Sent: 6. oktober 2013 19:42
To: users@subversion.apache.org
Subject: Re: File size different downloaded compared to uploaded

On 06.10.2013 10:33, Helge Rossvoll wrote:
>
> 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.
>
>  
>
> Anyone with any idead?
>

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.

-- Brane

--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: File size different downloaded compared to uploaded

2013-10-06 Thread Andy Levy 
Please be sure to Reply To All so that responses go back to the list.

On Sun, Oct 6, 2013 at 2:02 PM, Helge Rossvoll  wrote:
> SVN repo is used for android ROM development.
> What we see now is that if we checkout the entire repo, .zip it and flash on 
> the phone it will flash, but when trying to run the bash scripts on the 
> phone, for instance install_kernel.sh it will fail.
> I assume this is due to the fact that the files are altered in some way.
>
> Checking the svn:eol-style parts now.

If you can't find any differences visually, then one or more
characters that aren't visible are getting changed - most likely EOL
markers. Use a diff tool to be sure.

If the scripts will only work the *NIX-style EOL markers, then set
svn:eol-style on those files to LF

> Sent: 6. oktober 2013 19:56
> To: Helge Rossvoll
> Subject: Re: File size different downloaded compared to uploaded
>
> On Sun, Oct 6, 2013 at 1:52 PM, Helge Rossvoll  wrote:
>> 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.
>
> What's the perceived problem in the first place? Have you checked the things 
> that Brane & I suggested you check, and if so what were the results?
>
> Auto-props *are* a client setting, and have nothing to do with the server. 
> svn:eol-style is also handled exclusively by the client. A change of server 
> should not be causing this to happen.
>
>> Sent: 6. oktober 2013 19:42
>> To: users@subversion.apache.org
>> Subject: Re: File size different downloaded compared to uploaded
>>
>> On 06.10.2013 10:33, Helge Rossvoll wrote:
>>>
>>> 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.
>>>
>>>
>>>
>>> Anyone with any idead?
>>>
>>
>> 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.
>>
>> -- Brane
>>
>> --
>> Branko Čibej | Director of Subversion
>> WANdisco // Non-Stop Data
>> e. br...@wandisco.com

RE: File size different downloaded compared to uploaded

2013-10-06 Thread Helge Rossvoll 
Client have native set for .sh files.
Files are created on windows, published to the debian SVN/apache server and in 
most cases checked out to windows machines.
Haven’t been able to get anyone using linux to test yet.

Med vennlig hilsen
Helge Rossvoll


-Original Message-
From: Andy Levy [mailto:andy.l...@gmail.com] 
Sent: 6. oktober 2013 20:06
To: Helge Rossvoll; users@subversion.apache.org
Subject: Re: File size different downloaded compared to uploaded

Please be sure to Reply To All so that responses go back to the list.

On Sun, Oct 6, 2013 at 2:02 PM, Helge Rossvoll  wrote:
> SVN repo is used for android ROM development.
> What we see now is that if we checkout the entire repo, .zip it and flash on 
> the phone it will flash, but when trying to run the bash scripts on the 
> phone, for instance install_kernel.sh it will fail.
> I assume this is due to the fact that the files are altered in some way.
>
> Checking the svn:eol-style parts now.

If you can't find any differences visually, then one or more characters that 
aren't visible are getting changed - most likely EOL markers. Use a diff tool 
to be sure.

If the scripts will only work the *NIX-style EOL markers, then set 
svn:eol-style on those files to LF

> Sent: 6. oktober 2013 19:56
> To: Helge Rossvoll
> Subject: Re: File size different downloaded compared to uploaded
>
> On Sun, Oct 6, 2013 at 1:52 PM, Helge Rossvoll  wrote:
>> 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.
>
> What's the perceived problem in the first place? Have you checked the things 
> that Brane & I suggested you check, and if so what were the results?
>
> Auto-props *are* a client setting, and have nothing to do with the server. 
> svn:eol-style is also handled exclusively by the client. A change of server 
> should not be causing this to happen.
>
>> Sent: 6. oktober 2013 19:42
>> To: users@subversion.apache.org
>> Subject: Re: File size different downloaded compared to uploaded
>>
>> On 06.10.2013 10:33, Helge Rossvoll wrote:
>>>
>>> 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.
>>>
>>>
>>>
>>> Anyone with any idead?
>>>
>>
>> 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.
>>
>> -- Brane
>>
>> --
>> Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. 
>> br...@wandisco.com

Re: File size different downloaded compared to uploaded

2013-10-06 Thread Mark Phippard 
On Sun, Oct 6, 2013 at 2:19 PM, Helge Rossvoll wrote:

> Client have native set for .sh files.
> Files are created on windows, published to the debian SVN/apache server
> and in most cases checked out to windows machines.
> Haven’t been able to get anyone using linux to test yet.
>
>
It sounds like the files should have svn:eol-style LF set, not native.

Otherwise, checking out these files on Windows will give them CRLF line
endings.

Nothing new here, BTW. SVN clients have always worked this way.


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: File size different downloaded compared to uploaded

2013-10-06 Thread Helge Rossvoll 
Yeah I understand.. Just cant wrap my head around why this worked fine on 
googlecode, and now suddenly the bash scripts woun't run.
Same client, same settings on client side.
Changing to LF for .sh scripts in the client didn't solve the problem.
Med vennlig hilsen
Helge Rossvoll



From: Mark Phippard [mailto:markp...@gmail.com]
Sent: 6. oktober 2013 20:29
To: Helge Rossvoll
Cc: Andy Levy; users@subversion.apache.org
Subject: Re: File size different downloaded compared to uploaded

On Sun, Oct 6, 2013 at 2:19 PM, Helge Rossvoll 
mailto:helge.rossv...@itet.no>> wrote:
Client have native set for .sh files.
Files are created on windows, published to the debian SVN/apache server and in 
most cases checked out to windows machines.
Haven't been able to get anyone using linux to test yet.

It sounds like the files should have svn:eol-style LF set, not native.

Otherwise, checking out these files on Windows will give them CRLF line endings.

Nothing new here, BTW. SVN clients have always worked this way.


--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: File size different downloaded compared to uploaded

2013-10-06 Thread Mark Phippard 
On Sun, Oct 6, 2013 at 2:42 PM, Helge Rossvoll wrote:

> Yeah I understand.. Just cant wrap my head around why this worked fine on
> googlecode, and now suddenly the bash scripts woun’t run.
>
> Same client, same settings on client side.
>
> Changing to LF for .sh scripts in the client didn’t solve the problem.
>
>
>
Did you move the repository via dump/load or did you just move the code
base to a new repository?  If the latter, then you might have set the svn:
properties differently than they were before.

While the behavior is implemented by the client (not the server), it is not
a "setting" of the client that you can toggle or control.  It is based on
the svn: properties of the item in the repository.

Since these are shell scripts, the svn:executable property may be another
one that is not set the same.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: File size different downloaded compared to uploaded

2013-10-06 Thread Helge Rossvoll 
We did indeed, start from rev 0 to make sure everything was clean when we moved 
from googlecode.

Med vennlig hilsen
Helge Rossvoll


From: Mark Phippard [mailto:markp...@gmail.com]
Sent: 6. oktober 2013 20:50
To: Helge Rossvoll
Cc: Andy Levy; users@subversion.apache.org
Subject: Re: File size different downloaded compared to uploaded

On Sun, Oct 6, 2013 at 2:42 PM, Helge Rossvoll 
mailto:helge.rossv...@itet.no>> wrote:
Yeah I understand.. Just cant wrap my head around why this worked fine on 
googlecode, and now suddenly the bash scripts woun't run.
Same client, same settings on client side.
Changing to LF for .sh scripts in the client didn't solve the problem.


Did you move the repository via dump/load or did you just move the code base to 
a new repository?  If the latter, then you might have set the svn: properties 
differently than they were before.

While the behavior is implemented by the client (not the server), it is not a 
"setting" of the client that you can toggle or control.  It is based on the 
svn: properties of the item in the repository.

Since these are shell scripts, the svn:executable property may be another one 
that is not set the same.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: File size different downloaded compared to uploaded

2013-10-06 Thread Ryan Schmidt 

On Oct 6, 2013, at 13:42, Helge Rossvoll wrote:

> Yeah I understand.. Just cant wrap my head around why this worked fine on 
> googlecode, and now suddenly the bash scripts woun’t run.
> Same client, same settings on client side.
> Changing to LF for .sh scripts in the client didn’t solve the problem.

If you're talking about the autoprops setting in your Subversion config file, 
that only takes effect when you add a new file to the repository. For existing 
files, you'll have to locate them and explicitly change their svn:eol-style 
property and commit the change.

RE: File size different downloaded compared to uploaded

2013-10-06 Thread Helge Rossvoll 
Yeah. Changed to LF in client, deleted a few .sh files and comitted them again.
Same issue still. Might of course be something else than svn:eol-style :)

Med vennlig hilsen
Helge Rossvoll


-Original Message-
From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] 
Sent: 7. oktober 2013 03:55
To: Helge Rossvoll
Cc: Mark Phippard; Andy Levy; users@subversion.apache.org
Subject: Re: File size different downloaded compared to uploaded


On Oct 6, 2013, at 13:42, Helge Rossvoll wrote:

> Yeah I understand.. Just cant wrap my head around why this worked fine on 
> googlecode, and now suddenly the bash scripts woun't run.
> Same client, same settings on client side.
> Changing to LF for .sh scripts in the client didn't solve the problem.

If you're talking about the autoprops setting in your Subversion config file, 
that only takes effect when you add a new file to the repository. For existing 
files, you'll have to locate them and explicitly change their svn:eol-style 
property and commit the change.

C89 bug when compiling on MinGW (not subscribed)

2013-10-06 Thread carlo.bra...@libero.it 
Hello,
I compiled successfully SVN on MINGW+MSYS but I got this error during the 
process:

/bin/sh /home/Carlo/subversion-1.8.3/libtool --tag=CC --silent --mode=compile 
gcc -std=c89  -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE   -g -O2  -g -O2  -I.
/subversion/include -I./subversion -I/mingw/include/apr-1   -
I/mingw/include/apr-1 -o subversion/libsvn_subr/win32_xlate.lo -c 
subversion/libsvn_subr/win32_xlate.c
subversion/libsvn_subr/win32_xlate.c:81: error: redefinition of typedef 
'win32_xlate_t'
subversion/libsvn_subr/win32_xlate.h:30: error: previous declaration of 
'win32_xlate_t' was here
subversion/libsvn_subr/win32_xlate.c: In function 
`svn_subr__win32_xlate_to_stringbuf':
subversion/libsvn_subr/win32_xlate.c:205: warning: assignment makes pointer 
from integer without a cast
make: *** [subversion/libsvn_subr/win32_xlate.lo] Error 1

Actually, the subversion/libsvn_subr/win32_xlate.h declares some functions 
with an opaque structure called win32_xlate_t, but since the build process is 
feeding the option "-std=c89", it fails because it seems that the opaque and 
complete structures are not supported in that dialect at the same time.
Probably, this defect has been never seen before because perhaps until now SVN 
for native Windows has been never compiled with GCC (cygwin is POSIX, not 
WIN32, so it does not count).
The missing conformance to C89 can be resolved by either declaring the 
complete structure inside subversion/libsvn_subr/win32_xlate.h, or by making 
that parameter in those functions really opaque, with a pointer to void that it 
will be eventually casted later to win32_xlate_t.

I have prepared two patches for this bug: each patch implements one of the two 
solutions described above so you can use the best for you (anyways, they are 
both easy fixes).

Sincerely,

Carlo Bramini.

logging externals commit

2013-10-06 Thread Zvika Castel 
Hi,

In general, it's about seeing the log of a commit to an externals file.
I will try to describe the situation:
I have folder named "Master" with file named "FileA.txt" in it.
Somewhere in the project tree I have also a folder named "Slave" with an 
externals "FileB.txt" pointing to "Master/FileA.txt"
Now, on Update I get two files on my working directory tree, FileA under Master 
and FileB under Slave.
A developer changed "FileB.txt" and commit his changes (at this point changes 
were made on FileA.txt because it's a "share").
Now, I open the log to see all the changes made on "Slave" folder and...
There is not a single sign that someone has change "FileB.txt"

I know what SVN is doing under the hood, I know I can see the log of "Master" 
folder and see the transaction over there, but...
What I expected, as a developer, that SVN will show me MY actions, not his.
When I open the log of "Slave" folder I want to see that someone has changed 
"FileB.txt".

Consider this as a feature request.

Regards,
Zvika Castel
Software Configuration Manager
The Tel Aviv Stock Exchange
Phone: 972-(0)3-5677-490
eMail: zvi...@tase.co.il
[cid:image001.gif@01CEC2AC.98ABC340]

Visit the Tel Aviv Stock Exchange's Website www.tase.co.il 

<>

Re: File size different downloaded compared to uploaded

2013-10-06 Thread Thorsten Schöning 
Guten Tag Helge Rossvoll,
am Montag, 7. Oktober 2013 um 06:18 schrieben Sie:

> Yeah. Changed to LF in client,

svn:eol-style-Property, file content or both?

> deleted a few .sh files and comitted them again.
> Same issue still. Might of course be something else than svn:eol-style :)

You can make sure by removing svn:eol-style and saving the file again
with LF file endings. Wherever the file is checked out now it should
have the same Hash as Subversion doesn't change the content.

Besides line endings you should check for svn:executable, too. This
gets lost on Windows checkouts, if you check out on Windows, tar/zip
or whatever and push to some Linux based environment, the files won't
have their executable bit preserved.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow