Just changing the Subject line to match the topic of conversation. - Julian
On Mon, 2010-02-15 at 01:43 +0100, Stefan Sperling wrote: > On Sun, Feb 14, 2010 at 07:31:07PM -0500, Glenn Maynard wrote: > > On Sun, Feb 14, 2010 at 6:47 PM, Mark Mielke <m...@mark.mielke.cc> wrote: > > > Heck, if one can ask the server for missing pristine copies - why not > > > treat > > > it like a "least recently used" cache, where users can cap the shared > > > pristine copy to a certain size, and it will download the missing pristine > > > copies as required when it needs them, rather than always keeping > > > everything > > > local? > > > > Putting aside shared data, being able to tell Subversion to go back to > > CVS's "download the prestine copy as needed" behavior (eg. a > > "svn:no-cache" property) would be extremely useful. For large > > compressed binaries (eg. .ogg files, the bulk of my large data), > > binary diffs are utterly useless, so the benefits of the prestine > > files around are mostly lost (except for, off-hand, svn revert). For > > me, this would solve the prestine-overhead problem completely. If you > > have many gigs of data that *can* be diffed, however, it obviously > > wouldn't be as effective for you as shared prestine data would be. > > Making the pristine store optional should be easy and I've seen > this mentioned before: > http://subversion.tigris.org/issues/show_bug.cgi?id=525#desc19 > > > On Sun, Feb 14, 2010 at 7:14 PM, Stefan Sperling <s...@elego.de> wrote: > > > As I said, I don't expect pristines to clean up themselves. > > > > Sorry; if you said that, I missed it and can't find it. > > I was not explicit about it in my first reply. It was between the lines, > and in my head :) > > > > But if it's not a design goal, then there's no point in complaining > > > when the feature goes away. Either the feature is part of the design > > > or it isn't. > > > > It's a use case that's always been handled by SVN and CVS. When you > > have a feature that's been supported for that long, which real users > > expect to be able to do, then it's an oversight in the design if it > > doesn't mention it. That doesn't make it any less of a real use case > > whose support is disappearing. (Fortunately, it's a relatively minor > > use case; I'll survive.) > > I agree that, in general, it sucks if something suddenly stops working. > And I also think people missing this feature will survive. > > Stefan
