On Feb 13, 2010, at 19:00, Glenn Maynard wrote: > 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.)
You bring up a lot of the same questions I have about the new working copy design. I assume the developers have considered all of this carefully and are making the best choices they can. I plan to wait until 1.7 is released and then just see what's happened. I understand some (all?) of this is already implemented in trunk so you can of course build from there and see how it works already.
