These comments are exactly what I like about internet, people telling 
someone that he has no Idea of what he wants when they are the ones who 
have not understood the problem. (no hard feelings! I am just surprised 
sometimes by other people answers! :D)

Other people in contrast, understood precisely what I meant, and even 
provided links to other people requesting the same:
https://svn.haxx.se/users/archive-2009-07/0107.shtml (Thank you very much, 
Daniel)

I precisely know what I need, because I am doing it manually, we, as 
programmers, (should) like automate, not to do things manually.
I have precisely expressed what I need:

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 (I mean manually, I know which 
files need this process, the ones with native-eol attribute, I just don't 
want to check it  manually).
-Change date of files.

If this could be done my process would be:
-TortoiseSvn - Change project settings to do UNIX conversion for files that 
have --native-eol attribute (1 setting per project or even global option 
for the program). Do this ONCE each time I need to change the operating 
mode.
-Just work normally - Update - Commit.
-DONE!!!.

If this was possible, I would not have use another tool: SVN in MINGW 
command line, export command in SVN or a custom script, and all would be 
done from the same user interface (TortoiseSvn).

I agree that, after seeing that SVN functionality is provided to 
TortoiseSvn by the SVN command line utility, maybe, I have asked at the 
wrong group.

I will ask in SVN or even check the code myself (that normally takes much 
more time because I am not familiar with the code base, and I have to first 
understand someone else code, then modify it, deal with the configure 
scripts and potential building errors, test...You all know). People 
involved in the project can do this kind of change much quicker.

If SVN ever implement this functionality I may come back to gently ask if 
it is possible to add this functionality to the GUI.

On Friday, June 18, 2021 at 9:29:48 AM UTC+2 H. Niemann wrote:

> 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]> 
> *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%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].
>
> 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].
>
> 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/ff19cf73-3696-45a2-a787-5191b9c97aadn%40googlegroups.com.

Reply via email to