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

RE: Re: Configuration files...

From: Brian Erickson <erickson_at_BAUERCONTROLS.com>
Date: 2007-01-08 23:19:03 CET

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?

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.

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.

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?

The repository is stored on a server named Snidley. Everyone will
access the repository through a share named: svn

My repository looks like this:
/pcs/trunk
          /4.1
          /4.2
    /branches
             /build
                   /4.1
                   /4.2
                         ...
             /QA
                    /4.1
                  /4.2
            ...
    /release
          /4.1
          /4.2
            ...

Only the 'librarian' user can commit to the release folder, and the
build or QA branches.

We regulary are developing on multiple versions of the same product
(PCS) at the same time. Usually just two but it is sometimes more. So,
I think I need to keep the source code in separate branches. I don't
think I'm smart enough to separate things by revision of the product
otherwise.

BTW, none of this is 'live' yet. Today we are using PVCS. We plan on
converting in Feb. or March.

Brian

-----Original Message-----
From: Andy Levy [mailto:andy.levy@gmail.com]
Sent: Monday, January 08, 2007 4:04 PM
To: Brian Erickson
Cc: users@subversion.tigris.org
Subject: Re: Configuration files...

On 1/8/07, Brian Erickson <erickson@bauercontrols.com> wrote:
>
>
> Hi all,
>
> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
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:19:24 2007

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

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