I FORGOT to repeat this: -I can't change the EOL property on the server/project, it works fine for other build environments, so I can't commit the change in the property.
For the files I meant: -Hundreds to thousands of files, but not all of them need this conversion, but we have to check them all to check its properties. -Not very big, from a few KB to some hundreds of KB. On Sunday, June 27, 2021 at 11:56:16 PM UTC+2 Visenri wrote: > 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/a4bf1621-ac06-451d-aa3e-803939efb49bn%40googlegroups.com.
