On Sat, Feb 13, 2010 at 7:10 PM, Ryan Schmidt <subversion-20...@ryandesign.com> wrote: > "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.
A database representing the whole working copy? That's odd--I can't think of how that could generally handle actions like cloning a whole WC (cp -a wc1 wc2), pulling a piece out of a WC creating a new WC as a result (mv wc1/trunk .; rm -rf wc1) and renaming a WC (mv wc1 wc1~), all of which work with the current system (and all of which I use with varying frequency). Putting text-base in Sqlite would be unfortunate. One of the great things that could be done with the current format would be to support COW filesystems, which are under active development and hopefully will be fairly common in a few years. That would eliminate the 2x data overhead, while still supporting client-side diffs. I'm not sure that Sqlite is any good at storing large, changing files, either (database fragmentation). (I don't know what the actual design is looking like; I've looked over http://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/design, but of course it's rather hard to grasp the overall design from a thirty page design notepad.) > 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. That's true, and simplifies the idea significantly. I do think it's reasonable to require this be set at checkout time. Another category of use cases comes to mind: "svn diff" can operate across WC's, so it should function across WC's checked out with different newline styles. (I don't see myself actually trying to implement this--not in the next few months, anyway--so I didn't poke in to see how hard this would be.) > 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 I'd avoid any design that involves rearranging core features like svn switch, which I suspect would make it a much harder sell to the core developers, who would rightly ask "why are we making major interface changes for a minor feature?". -- Glenn Maynard
