Re: Changing the "native" newline mode

On Feb 13, 2010, at 16:09, Glenn Maynard wrote:

> 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.

"svn export" already has a "--native-eol" switch. This is easy because after exporting, Subversion doesn't have to deal with that directory anymore. But as a fellow user I think it would fit nicely to have the same switch on "svn checkout", which would make that working copy always use the indicated "native" eol-style. Where to store this fact? In Subversion 1.7, working copy metadata will no longer live in .svn directories but in a central sqlite database, so there's probably a place in there where native eol-style could be stored. If Subversion does not already store the native eol-style of the working copy somewhere, this would probably be a good thing to add, regardless of whether we add a mechanism for requesting an alternate eol-style.

I'm not sure we need a mechanism to switch an existing working copy to a different native eol-style. If we do, "svn update --native-eol CRLF" would be one possible syntax to consider.

Another possibility would be to overload "svn switch" further. "svn switch" already has two meanings: 1) re-associate the working copy with a different path within the same repository ("svn switch NEWURL") and 2) inform the working copy that the repository has moved to a different URL ("svn switch --relocate OLDURL NEWURL"). We could add a third function: 3) change the native eol-style ("svn switch --native-eol CRLF"). However, rather than adding a third function to "svn switch", I'd be more in favor of going the other way: reducing "switch" to a single functionality (what is currently plain "svn switch"), and moving the existing "svn switch --relocate" function to a new command "svn relocate", since switching and relocating really don't feel related to me at all and putting them under the same main verb just leads to confusion.
Received on 2010-02-14 01:11:25 CET