Greg Hudson wrote:
> On Fri, 2005-04-29 at 13:11, steveking wrote:
>>Is the '.subversion' directory you mention here the one where the also
>>the 'config' and 'server' file is located? (%APPDATA%\Subversion on
>>If yes, then I think that would be the best way to go with server-side
>>configs. We could store them in a subfolder 'serverconfig' like e.g. the
>>authentication data is stored now.
> Working copies can be used by more than one user. It would be a bug
> (perhaps not a terribly serious one) if you couldn't "svn revert" a home
> directory without access to the repository because you weren't the one
> to check it out.
> Also, we should not be assuming that server configuration comes in the
> form of a repository config file. Personally, I think all
> server-to-client configuration goals can be accomplished by adding new
> directory properties.
Seems I have some problems understanding you guys here, so please don't
take this the wrong way.
- yes, working copies can be used by more than one user. But why would
that be a problem for server configs? I mean those configs are intended
to pass configurations/other information from the server to *all*
working copies (not just individual users). So a working copy used by
several people shouldn't be a problem?
- you can't do an 'svn revert' on a working copy and get rid of the
cached auth data either. That's never bothered anyone AFAIK. Also,
server configs are intended to be 'dictated' by the server (overridable
by the user perhaps), and a 'revert' would therefore not make much
sense. I think of such server configs like changes you get when you do
an 'svn update' - and you can'r 'svn revert' such changes either. You'd
have to do a merge to get rid of such changes.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Apr 29 20:24:22 2005