On Sat, Feb 13, 2010 at 11:11 AM, Tyler Roscoe <tyler_at_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-2010a_at_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
Received on 2010-02-13 23:10:27 CET