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.
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
--
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
tortoisesvn...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tortoisesvn/513a116f-186d-4ded-856e-9be24ac58569n%40googlegroups.com.
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
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/AM8PR10MB40671B2D835146169FC02BFEFC0F9%40AM8PR10MB4067.EURPRD10.PROD.OUTLOOK.COM.
Hi Visenri,
is this
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 <torto...@googlegroups.com>
Gesendet: Donnerstag, 17. Juni 2021 20:17
An: TortoiseSVN <torto...@googlegroups.com>
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:
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/c7bcc5ad-d888-459f-b211-bbf2ee1277e9n%40googlegroups.com.
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 <torto...@googlegroups.com>
Gesendet: Samstag, 19. Juni 2021 01:37
An: TortoiseSVN <torto...@googlegroups.com>
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)
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 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.