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

WC-NG - on detachable WCs and pristine store options [was: Changing the "native" newline mode]

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Mon, 15 Feb 2010 10:12:17 +0000

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 <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.
>
> 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 <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.
>
> 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
Received on 2010-02-15 11:12:57 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.