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

Re: WC-NG - on detachable WCs and pristine store options

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 22 Feb 2010 08:51:50 +0100

On Sun, Feb 21, 2010 at 09:24:20PM +0100, Steinar Bang wrote:
> > On Mon, 2010-02-15 at 01:43 +0100, Stefan Sperling wrote:
>
> >> 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
>
> I think optional pristine store needs to be possible to control on the
> file level. Not just on or off.

This would be like telling svn to not ever cache the pristine
text for some particular file. Fine, I can see use cases for this.
But what kind of interface would you like to control this?

"Don't ever cache foo.c"!
What if another WC uses foo.c as well?

"Don't ever cache the file with the checksum 49f910..." ?
Bit inconvenient... ?

> On a different note, the bug comment, the above URL is a response to
> mentions: "open subversion up to new markets: home backup and
> multiple-computer synchronization"
>
> I use svn for some of that: I version parts of my home directory, mostly
> config files, but also some replicated ordinary files.

Using svn for this does not make it a first class use case :)
If people use svn for this, fine. But svn isn't rsync, so if rsync does
this better, use rsync.

> One thing I'm missing for my use case is the possibility to persist
> write privileges (I have some files with login secrets that I would like
> to be set to go-rwx, or the equivalent).

You can't possibly be the first person to bring this up during the last
10 years. I'm not sure what prior discussions about this topic ended up
with, but maybe searching the archives would give some answers.

Stefan
Received on 2010-02-22 08:52:34 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.