On Sat, Feb 13, 2010 at 11:11 AM, Tyler Roscoe <ty...@cryptio.net> wrote: > I haven't been following this thread closely but it seems that your > complaint is the classic, "Doctor, it hurts when I do this." Several > people in the community have suggested, "Then don't do that." I would > take this sage advice (i.e. don't share working copies across platforms) > or at least one of the proposed workarounds (I saw the idea of setting > eol-style to CRLF; did someone suggest running unix2dos before using > the working copy on your Windows box?) rather than complaining that the > advice is not helpful.
I've explained in reasonable detail why I want to do what I want, and why none of these workarounds work. Saying "just don't do that" is ignoring everything that's been said. "It hurts when I breathe!" "Then what should you stop doing?" On Sat, Feb 13, 2010 at 4:16 PM, Ryan Schmidt <subversion-20...@ryandesign.com> wrote: > Checking out files with eol-style:native will give them the native line > ending style matching the client that did the "svn checkout". I am not > certain what happens with "svn update" later: do files get the eol-style of > the client currently doing the update or of the client that originally did > the checkout? The latter would mean that the native eol-style was stored > somewhere in the .svn directories by the client that did the svn checkout. To > discover if this is the case, you could check out a working copy on UNIX and > check out a working copy from the same URL on Windows and then diff them. If > they differ, you may be able to use that information to patch the contents of > the .svn directories on your UNIX box on the SMB share, in addition to > running a tool like unix2dos or ux2dos to fix the line endings in the actual > files. However, this advice will get me yelled at by the list, because we > cannot recommend modifying the contents of the .svn directories manually for > any reason. So I'm merely saying you could do this; I'm not recommending you > do this. Even if that worked, I'm pretty sure it would break badly the next time a new directory was created from an update. I'll stick with manually repairing newlines for now. I suspect that it's not a massive project to actually implement this properly; fundamentally, it probably means adjusting svn_wc__get_eol_style to allow substituting "native" for one of the other EOL modes, based on a working-copy-local setting (not a stored property). When this setting is changed, any affected eol-style:native files would need to be converted (nothing new here; changing eol-style itself does exactly that). The tricky part is in the supporting details: where to put that setting and how to change it, what happens if you svn switch a directory with this setting, etc. Anyhow, while it might be too niche a feature for inclusion in Subversion, it's definitely not outside the overall design, as Tyler suggests. This fits very naturally into Subversion's concept of newline handling. -- Glenn Maynard
