On Jan 8, 2007, at 16:19, Brian Erickson wrote:
> Andy Levy wrote:
>
>> On 1/8/07, Brian Erickson wrote:
>>
>>> I'm trying to understand how Subversion deals with system-wide
>>> configuration properties and can't figure it out. I've read the
>>> docs
>>> but am still clueless. I'm hoping someone can help me.
>>>
>>> I'm using windows XP and all my users will access the repository
>>> using
>>> the FILE:// syntax.
>>>
>>> 1) Is there a way to set options that every user accessing the
>>> repository will have?
>>> Specifically, I'm looking to ignore things like object files and
>>> such as well as an editor for when the -m option is missing.
>>
>> Client configuration is per-user. There is currently no way to set a
>> particular configuration from the "server" (I put this in quotes
>> as you
>> have no real server when using file://).
>>
>>> 2) If it's possible, where do these file(s) go? what is the format?
>>
>> Each user's config is in %APPDATA%\subversion\config . It's a
>> plain-text
>> file. Documentation is included within.
>>
>>> 3) Right now, I've locked down branches in the tags folder using the
>>> pre-commit hook. Can I do the same thing in the "authz" file
>>> (remember I'm using the FILE:// syntax)?
>>
>> Using file://, it's all or nothing - users either have access to the
>> repository (via the host OS's permissions - NTFS & share
>> permissions in
>> your case, I'm guessing), or they don't. This means they can very
>> easily
>> hose the whole setup.
>>
>> file:// really isn't suited to a multi-user environment - it's
>> best for
>> single-user setups, and testing/debugging. You really ought to
>> consider
>> serving via svnserve or Apache.
>
> It's interesting that the Subversion developers chose to put the
> client
> configuration in a hidden folder...Did I just miss this in the docs?
The book does state the name and location of the configuration
directory, and does note that this directory is usually hidden. It
does not seem to say why.
http://svnbook.red-bean.com/en/1.2/
svn.advanced.html#svn.advanced.confarea
On Unix, it is usual for programs to put their configuration files
into directories in the home directory whose names begin with a
period, which by default makes them hidden. I don't know what's usual
on Windows.
> You're right there is no server but everyone is accessing a repository
> on a server. That's why the hooks work. For each repository there
> appears to be a hooks folder. I was hoping that I could put some
> files
> somewhere else on the server to define a common configuration.
But unfortunately, you can't; Subversion doesn't have server-side
client configuration.
> My situation appears to be quite different from most users sending to
> this list. I will never have a customer accessing the repository.
> The
> only people accessing the repository will be programmers working for
> Bauer Controls. The repository is stored on an in-house server and
> (at
> least today) we have no need to access it from outside the company.
>
> Further more none of our programmers have full time
> responsibilities in
> a particular sub-set of our projects. The net effect is that our
> programmers needs to have access the entire repository all of the
> time.
That setup doesn't sound so uncommon. We also had our repository on a
central development server in the same building as all the
developers. We ended up serving with apache2 because as web
developers we're familiar with it, and it let us access the
repository from outside the company securely using https, which was a
bonus for those times when someone needed to check something out from
home.
> Given all this, I'm interested in why you say the file:// isn't suited
> to multi-user scenarios. It seems to fit quite nicely for me. I've
> used hooks to lock down the parts of the repository that are
> restricted
> to a particular user. Am I going to run into file corruption
> issues or
> something?
Anyone who has access to a repository via file:// protocol has
*complete* access to it. You can install hooks, but anyone can edit
or remove them, or copy the entire repository to their local disk to
use as they please. Anyone can even delete the entire repository
using their OS-level file browser with your only recourse being to
restore from backups, if you have them.
By contrast, if you serve via svnserve or apache2, only the svnserve
or apache2 user has the ability to read from and write to the
repository, and your users are then actually restricted to the access
you define with hooks or other means.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 8 23:37:34 2007