Hi Visenri, is this
* What I don't want is: * -Keep track of which files need this process. the core of your problem? Subversion is a version control *tool*. If I understand you, you do not want a tool and advice how to solve your problem. You want magic that solves your problem for you, and you do not even want to know what your problem exactly is. I doubt you will find a magic solution in this mailing list. You were presented different approaches, and we might come up with some more, and you could choose the one that fits your problem best - but only if you want to understand your problem in detail first. You *need* an understanding which files are affected and why. IMHO this is crucial for finding a solution that fits. Hartmut Von: Visenri via TortoiseSVN <[email protected]> Gesendet: Donnerstag, 17. Juni 2021 20:17 An: TortoiseSVN <[email protected]> Betreff: Re: Feature to force svn:eol-style native to LF or any other valid value. 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<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsvnbook.red-bean.com%2Fen%2F1.7%2Fsvn.ref.svn.html%23svn.ref.svn.sw.native_eol&data=04%7C01%7Chartmut.niemann%40siemens.com%7Cf6049bcb33754cce0ee508d931bc1ef1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595506303260848%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3ZjwEdfW9yNlIQgqge%2BsEauzxjG1WIyVhUKYIzJM8OE%3D&reserved=0>: 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. -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]<mailto:[email protected]>> Gesendet: Mittwoch, 16. Juni 2021 07:42 An: TortoiseSVN on behalf of Visenri <[email protected]<mailto:[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]<mailto:[email protected]>> Gesendet: Dienstag, 15. Juni 2021 22:30 An: TortoiseSVN <[email protected]<mailto:[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]<mailto:[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%7Cf6049bcb33754cce0ee508d931bc1ef1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595506303270809%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wHuSZOhZ02XZMBpgagrPLRrRKX8SbaOx6uSKvOwWuJY%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]<mailto:[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%7Cf6049bcb33754cce0ee508d931bc1ef1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595506303270809%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gm1fRFOtao2vNHTcIhHvYvg2H%2F4Zuga0PLS675ypfXA%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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/c7bcc5ad-d888-459f-b211-bbf2ee1277e9n%40googlegroups.com<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Ftortoisesvn%2Fc7bcc5ad-d888-459f-b211-bbf2ee1277e9n%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Chartmut.niemann%40siemens.com%7Cf6049bcb33754cce0ee508d931bc1ef1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595506303280758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CwFUyjmoEHiuavhU7ld%2BQWeHTQPNkWb%2FjVMvZTqja4U%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/AM9PR10MB4071AFC7EBB6162025C37539FC0D9%40AM9PR10MB4071.EURPRD10.PROD.OUTLOOK.COM.
