On Fri, Feb 9, 2018 at 8:04 PM, Bo Berglund <bo.bergl...@gmail.com> wrote: > On Fri, 9 Feb 2018 13:40:43 +0100, Johan Corveleyn <jcor...@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.
You'll need a working copy for that. > 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 I don't think that will work. The *.txt will only be interpreted by your shell, and it will not be passed to the recursive propset command ... so it'll only apply the propset to *.txt files in the current directory. Perhaps you can whip something up in combination with the find command: find . -name '*.txt' -exec svn propset svn:eol-style native {} \; or something like that (note: you don't need to put quotes around the value, otherwise the value will actually become 'native', instead of native). > And then a svn commit > > Would this work? > What would happen if a file already has the requested property? I think that will work. Not sure what happens if the file already has the property ... but it's easy to try it out, so just give it a try :-). ISTR there used to be a helper script to do this (to apply a certain autoprops configuration to your working copy ... svn-apply-autoprops.py or .pl or something), but I can't find it. Maybe it was in the contrib folder which has been removed since (you might be able to find a version of it googling). -- Johan