[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: EOL problems in cvs2svn converted repository

From: Bo Berglund <bo.berglund_at_gmail.com>
Date: Fri, 09 Feb 2018 20:04:23 +0100

On Fri, 9 Feb 2018 13:40:43 +0100, Johan Corveleyn <jcorvel_at_gmail.com>
wrote:

>> We use VisualSVN with svn version 1.9.7 on the server
>
>Standard dump/load cannot do this.
>
>However, you might be able to do it using this tool:
>https://github.com/jwiegley/svndumptool
>
>(it can manipulate dump files by setting properties and stuff like
>that, and performing various eol fixes)
>
>I'm wondering how robust this is though ... make sure to doublecheck
>the result (for instance by checking out / exporting some of these
>files from different points in history).
>
>The reason why I'm wondering is that, internally (in the repository) a
>text file is stored in "normalized form" (which is LF-terminated) if
>you have the svn:eol-style=native property set. But if it's not set,
>svn doesn't alter the incoming file in any way (it could be binary for
>all svn knows), so if that file was committed from Windows, it will
>probably be in CRLF format, so that's what will be stored in the
>repository. So changing this in historic revisions (in a dump file) is
>not just a question of adding the property, it also involves
>normalizing the corresponding file contents in the dump (and the dump
>format contains checksums and offsets, so manipulating actual contents
>in not easy).

OK, I think I will be OK with only setting the trunk version files
correctly, if possible. After all this is what the consultants will
use.
And the development IDE:s seem to be able to cope fine with UNIX style
source files (at least those I have tested with).

Someone suggested that this would do it, but I am not sure:

svn propset svn:eol-style 'native' -R *

And he did not say how to do it, for example if I have to do that
inside a working copy or if it is possible directly against the
repository.

In any case it seems like a dangerous proposition using * as file
spec, since there are binary files also in the repo (icons, images,
Windows executables, dll's etc).

So maybe a script like this (executed at the top of a working copy):

svn propset svn:eol-style 'native' -R *.txt
svn propset svn:eol-style 'native' -R *.c
svn propset svn:eol-style 'native' -R *.h
svn propset svn:eol-style 'native' -R *.pas
svn propset svn:eol-style 'native' -R *.dpr
svn propset svn:eol-style 'native' -R *.ini
svn propset svn:eol-style 'native' -R *.conf
svn propset svn:eol-style 'native' -R *.py
svn propset svn:eol-style 'native' -R *.cpp
svn propset svn:eol-style 'native' -R *.lpr
svn propset svn:eol-style 'native' -R *.lpi
svn propset svn:eol-style 'native' -R *.bat
svn propset svn:eol-style 'native' -R *.iss
svn propset svn:eol-style 'native' -R *.xml
svn propset svn:eol-style 'native' -R *.gld
svn propset svn:eol-style 'native' -R *.inc
svn propset svn:eol-style 'native' -R *.dsp
svn propset svn:eol-style 'native' -R *.dsw

And then a svn commit

Would this work?
What would happen if a file already has the requested property?

-- 
Bo Berglund
Developer in Sweden
Received on 2018-02-09 20:05:24 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.