As someone already said, the translation occurs deep in the Subversion code 
used by TSVN. The function svn_subst_translation_required detects if 
translation is required and then the translation is done by wrapping the 
read()/write() calls (in the svn_wc__internal_translated_stream function). 
Thus you might be better off by asking at [email protected] 
(see http://subversion.apache.org/mailing-lists.html), but I think the 
answer will be the same as you have already received here. I checked the 
code quickly and I couldn't see any options related to this.

What you are asking for has been discussed before, for example:
https://svn.haxx.se/users/archive-2009-07/0107.shtml
(which was posted to the predecessor of [email protected]). The 
conclusion of that thread was the same as you have been advised here: Use 
two separate WCs and use a "local" tool for each WC - TortoiseSVN (GUI or 
CLI) for the "Windows-wc" and the Cygwin/WSL command line client for the 
"Unix-wc"

Kind regards,
Daniel Sahlberg


torsdag 17 juni 2021 kl. 20:17:06 UTC+2 skrev Visenri:

> 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/627df976-3cf1-45c2-a9f7-4894ea05892bn%40googlegroups.com.

Reply via email to