On Sat, Feb 13, 2010 at 7:10 PM, Ryan Schmidt
<subversion-2010a_at_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
Received on 2010-02-14 02:01:04 CET