Here we go again. Thank you for apologizing, as I said, no bad feelings. As I said, I can say it louder, but not clearer:
-I need to emulate a Unix behavior with TSVN. -When I get files I need to get files using LF for the ones that have the EOL flag set to native. -No need to check manually which files have the native EOL flag to change all of them to LF (we are talking of tens if not hundreds of files). I will answer your questions and I hope to clarify the subject (answers in blue): How many files are we talking about? -As I said, big projects, not doable by hand. How big are they? -Not very big, a few from 1k to a few 500k. What are they for? -Source code, makefiles, scripts, I don't care. What is the detailed use case, if you on your machine need the files stored CRLF locally one day and LF the other day (as you write “Do this ONCE each time I need to change the operating mode.”) The use case is as I said at least 3 times now: -Use my windows system with linux like tools with TSVN, no more worry about file conversions, just work normally, update-commit. -I do not change on a daily basis from one environment to the other, in fact I can keep one folder for each system if needed. -I just ask for the basic, being able to emulate the unix behavior when I update the folder. -I really don't know the details of how SVN work, I don't know if the conversion happens in the server or locally, but it does not matter. -If the server is the one that does the conversion, ok, change the information supplied to it to let it think I work on a linux machine. -If the conversion happens locally, ok, change the function that does the conversion and emulate the linux behavior. Doing a “commit here - update there” cycle when you need to switch operating mode (which can be a PITA – been there, done that)? -In dreamland: -It would also be useful to have also the feature to change all affected files if I change the option anytime, but this is dreamland: -I mean change the option, the folder & subfolders get inspected for files with EOL native and a list is presented with a confirmation to do the change. What makes you think that converting the files to LF style on the fly when you need them that style is not a viable solution? It is a viable option as long as: -It is done in an AUTOMATED way, I do not want to waste my time doing this process manually (looking for what files need conversion, the ones with the flag set to native). -It does not change the file date, flagging a change when i use some external tools (maybe I can live with the date changed, and not changing it may arise other problems, the important part is the automation). I have the gut feeling that switching file style from LF to CRLF and back should not be done on the file storage layer – TSVN is (in my point of view) more a versioning file system than a part of my build toolchain. If you dropped TSVN in favor of the old “have a CIFS/SMB/NFS with zip files or subdirectories for each version of the project” or a file versioning system/tool that treats all files as binary and never converts eol styles – how would you handle the EOL problem then? I don't know if I fully understand your point here. I am using TSVN as a versioning file system, I don't want to go back to files with subdirectories/zips for each version. In fact I just want the opposite, 1 folder with version control, forget about the #*$#! EOL and just keep working. And I can do that if I have the automated tools to do the conversion back and forth. Whenever I update the folder I need the program to rely on my setting to know what should it do with those files. If this is not enough to give you a very good Idea of the use case, I give up, I will create my own script using SVN to check the properties, create a log with that, open that file and search for the files with the property set to native and call recursivelly the conversion programs needed to change the files. But I think it would be much easier to to the simple change to allow the user to decide in TSVN what EOL do you need and forget about the rest. On Monday, June 21, 2021 at 10:13:21 AM UTC+2 H. Niemann wrote: > Hi Visenri, > > > > well said : „ 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) > > “ > > If you understand my post this way I must apologize. I don’t claim that > you do not have an idea what you want. But I do claim that you did non > express your problem in a way that I can understand. Currently you are > trying to discuss a solution, and I am still trying to understand whether > you are trying to solve a complex problem where solving a different problem > would make solving much easier. Yes, I believe that there is an easy > solution that does not involve using SVN the way you are suggesting at the > moment and I would love to find it. At a class about root cause analysis I > learned that asking “why is this” about five times gives a good chance to > find the real core of the problem. I don’t know whether we are at round two > or three at the moment 😊 > > > > You obviously meant something different than I thought when you wrote “Keep > track of which files need this process”, sorry for the misunderstanding > on my side. > > > > > > How many files are we talking about? How big are they? What are they for? > > > > What is the detailed use case, if you on your machine need the files > stored CRLF locally one day and LF the other day (as you write > > “Do this ONCE each time I need to change the operating mode.”) > > > > What are these operating modes? What happens if you need both modes > simultaneously or within 10 minutes? > > What makes you think that switching back and forth is faster, easier und > giving correcter results than having a working copy in each style (TSVN > for CRLF style and Cygwin for LF, for example) > > and doing a “commit here - update there” cycle when you need to switch > operating mode (which can be a PITA – been there, done that)? > > What makes you think that converting the files to LF style on the fly when > you need them that style is not a viable solution? > > > > I have the gut feeling that switching file style from LF to CRLF and back > should not be done on the file storage layer – TSVN is (in my point of > view) more a versioning file system than a part of my build toolchain. If > you dropped TSVN in favor of the old “have a CIFS/SMB/NFS with zip files or > subdirectories for each version of the project” or a file versioning > system/tool that treats all files as binary and never converts eol styles – > how would you handle the EOL problem then? > > > > > > But I do not want to convince you to do anything in a certain way. I am > trying to discuss and understand a problem as a way to learn more about > software engineering and how to solve interesting problems. And if I ask > “What …” this is not a rhetorical phrase. I do want to know your reasons > and then I want to question and discuss those. > > > > > > Hartmut > > > > > > *Von:* Visenri via TortoiseSVN <[email protected]> > *Gesendet:* Samstag, 19. Juni 2021 01:37 > *An:* TortoiseSVN <[email protected]> > *Betreff:* Re: Feature to force svn:eol-style native to LF or any other > valid value. > > > > 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. > > > -- 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/245d7a10-71ce-41ec-8c8b-6539d084bfd1n%40googlegroups.com.
