[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Changing the "native" newline mode

From: Glenn Maynard <glenn_at_zewt.org>
Date: Sun, 14 Feb 2010 19:31:07 -0500

On Sun, Feb 14, 2010 at 6:47 PM, Mark Mielke <mark_at_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.

On Sun, Feb 14, 2010 at 7:14 PM, Stefan Sperling <stsp_at_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.

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

-- 
Glenn Maynard
Received on 2010-02-15 01:31:41 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.