I found what I am asking for, but for export: http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.export.html
--native-eol *ARG* <http://svnbook.red-bean.com/en/1.7/svn.ref.svn.html#svn.ref.svn.sw.native_eol> : *Causes svn export to use a specific end-of-line sequence as if it was the native sequence for the client platform. ARG may be one of CR, LF, or CRLF.* But it's only available for export, What I am asking for is for update, so when I update I get the unix version of the file. Using external tools (e.g. unix2dos), I have to keep track of which files need the conversion, and I also lose the original file date. At least using the svn export all is handled automatically. I tried it and it works, but it generates an unwanted side effect, all files will have a changed date. I have not tried to overwrite the working dir (just to update the files with native-eol): svn export --force ./ --native-eol LF What I need in crystal clear words: -Do the update simulating my machine is a UNIX one. -Do it using the TortoiseSvn GUI if possible. What I don't want is: -Keep track of which files need this process. -Change date of files. On Wednesday, June 16, 2021 at 7:14:20 PM UTC+2 Bruce C wrote: > As I understand it, the aim is to to checkout a project. Then, depending > on tasks that are to be performed, different tools will be used to modify > the files. Some tools need Unix line endings and other tools need Windows > line endings. All tools are to be used on the same system [presumably > Windows since the request is being made for TortoiseSVN that is a Windows > only tool]. > > The observation is that Subversion can checkout the files differently, > using different line endings. The suggestion is to use this capability to > perform the line ending translations that you require, but this isn't > supported as it stands. > > Rather than try to change the Subversion, or TortoiseSVN, functionality to > fit these specific requirements, perhaps consider using a tool dedicated to > the task of changing line endings (e.g. unix2dos). Where the task requires > different line endings, use the tool to translate the files, perform the > task, and then run the tool to translate the line endings back again. I > would expect that the translations could be scripted. > > Alternatively, you have suggested that TortoiseSVN "has a function that > processes each occurrence of 'native' and converts it to CRLF in Windows". > I doubt that's how it works. I would expect that TortoiseSVN simply uses > the Subversion functionality. [Stefan provided a link to a description of > the Subversion functionality.] If that is the case, the request would need > to be directed at Subversion - not TortoiseSVN. Perhaps it might be > possible to request a feature that ignores the Subversion EOL property and, > instead, uses an override setting. Personally, I don't see that as a great > feature but perhaps this is an under-rated use case. However, it seems to > me that it'd still be better to perform the conversions directly and this > is something you can do without the need to await a change to Subversion. > > Hope this helps. > > On Wednesday, 16 June 2021 at 07:19:55 UTC+1 H. Niemann wrote: > >> Addendum: >> >> If I recall correctly, the cygwin svn command line clients think that >> native is LF. >> >> Maybe you investigate in that direction and just use mingw or Cygwin >> tools for managing the mingw WC. >> >> >> >> Hartmut >> >> >> >> *Von:* TortoiseSVN on behalf of H. Niemann <[email protected]> >> *Gesendet:* Mittwoch, 16. Juni 2021 07:42 >> *An:* TortoiseSVN on behalf of Visenri <[email protected]> >> *Betreff:* AW: Feature to force svn:eol-style native to LF or any other >> valid value. >> >> >> >> What I don’t understand: >> >> Are these files of the kind that needs LF style everywhere and the >> colleagues just use only machines where LF is native, >> >> or are these files needed in LF style on unixoid machines, CRLF style on >> Windows and you are the only one >> >> who has a use case where he needs them LF although the host is Windows? >> >> >> >> I believe there can not be a per-file-and-user property >> svn:eol-style=native_except_for_Visenris_MINGW_workingcopy_where_it_must_be_LF. >> >> What happens if you need a working copy on a linux machine? >> >> Or this would be a per-file-and-workingcopy property – this could >> probably be done, but I can hardly imagine a good use case for that. >> >> >> >> (Well actually, I had the use case that I wanted to disable an >> svn:external locally because you can exclude a file or directory >> >> from a working copy, but not an external – different story.) >> >> >> >> I would fix that in the build script. Leave the file >> svn:eol-style=native, have the editors do with it whatever they are used to >> and >> >> create a temporary file with the needed linefeed style as part of the >> build system. >> >> >> >> If, on the other hand, these files are normally used in unix >> environments, and everybody uses them LF style but >> >> your colleagues refuse to make that explicit by svn:eol-style=LF, then >> you have a people problem, not a technical one. >> >> >> >> Hartmut >> >> >> >> *Von:* Visenri via TortoiseSVN <[email protected]> >> *Gesendet:* Dienstag, 15. Juni 2021 22:30 >> *An:* TortoiseSVN <[email protected]> >> *Betreff:* Re: Feature to force svn:eol-style native to LF or any other >> valid value. >> >> >> >> I am telling you, I can't just: >> >> "set the svn:eol-style property to LF for those files you work with linux >> tools with." >> >> As I said this property is ok as it is for other people and I can't >> commit this change in svn properties. >> >> >> >> My suggestion is very simple: >> >> TortoiseSVN surely has a function that processes each occurrence of >> 'native' and converts it to CRLF in Windows. >> >> I just need a per project (repository) property to allow me to change the >> behavior of that translation function when I need Unix tools, so: 'native' >> -> LF. >> >> >> >> I just want to make TortoiseSVN behave like I am in a Unix machine. >> >> >> >> If anytime I need to use windows tools that need 'native' translated to >> 'CRLF', I just change the global setting and next time I update the files I >> will have files with that conversion done. >> >> >> >> >> >> On Tuesday, June 15, 2021 at 6:29:27 PM UTC+2 Stefan wrote: >> >> On Saturday, June 12, 2021 at 3:23:30 PM UTC+2 Visenri wrote: >> >> >> Please, take another look at the description of the problem. >> >> I can't change the eol-style property of the affected files, because the >> value 'native' is the right one for pure windows and unix users. >> >> >> >> The problem is, in windows, sometimes, I work in a mixed environment, >> with some linux-like tools included in MINGW, so, it is necessary to >> translate eol-style 'native' to 'LF' not to 'CRLF', what I am asking for is >> a way to convince TortoiseSVN that I am using unix tools despite running >> TortoiseSVN in windows. >> >> So, when it will see a eol-style 'native' it will use 'LF' like in a unix >> environment. >> >> >> >> you can set the svn:eol-style property to LF for those files you work >> with linux tools with. >> >> However if you want different eol-styles depending on what tools you use, >> then that's not possible. I mean how would svn know which tools you like to >> use today and which ones tomorrow??? >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "TortoiseSVN" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tortoisesvn/513a116f-186d-4ded-856e-9be24ac58569n%40googlegroups.com >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Ftortoisesvn%2F513a116f-186d-4ded-856e-9be24ac58569n%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Chartmut.niemann%40siemens.com%7C45736289325e4050ba8e08d930898484%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637594189460538195%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fJDoFEBXZI6c6p%2FAPgVxZX8hHb%2BnYxZ7CCwv1a6rVpg%3D&reserved=0> >> . >> >> -- >> You received this message because you are subscribed to the Google Groups >> "TortoiseSVN" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tortoisesvn/AM8PR10MB40671B2D835146169FC02BFEFC0F9%40AM8PR10MB4067.EURPRD10.PROD.OUTLOOK.COM >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Ftortoisesvn%2FAM8PR10MB40671B2D835146169FC02BFEFC0F9%2540AM8PR10MB4067.EURPRD10.PROD.OUTLOOK.COM%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Chartmut.niemann%40siemens.com%7C45736289325e4050ba8e08d930898484%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637594189460538195%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d%2BbCeEByEsB%2Fl%2FgFOTOh%2BO59I3Hb9wh8Kv2oK7VnT%2Bg%3D&reserved=0> >> . >> > -- You received this message because you are subscribed to the Google Groups "TortoiseSVN" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/c7bcc5ad-d888-459f-b211-bbf2ee1277e9n%40googlegroups.com.
