> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: Monday, January 08, 2007 8:59 PM
> To: Brian Erickson
> Cc: Ryan Schmidt; users@subversion.tigris.org
> Subject: Re: Re: Configuration files...
>
> On 1/8/07, Brian Erickson <erickson@bauercontrols.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Ryan Schmidt [mailto:subversion-2007a@ryandesign.com]
> > > Sent: Monday, January 08, 2007 5:37 PM
> > > To: Brian Erickson
> > > Cc: Andy Levy; users@subversion.tigris.org
> > > Subject: Re: Configuration files...
> > >
> > > 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.
> > >
> >
> > It's actually quite easy to restrict access to the hooks
> folder so the
> > scripts can't be removed or modified.
>
> But that doesn't protect the repository contents.
In my case is does. The only protection I want/need is for the three
special folders. Two underneath branches and everything underneath the
release (tags) folder. The hooks protect those.
I had thought, from reading posts here, that it was common practice to
use hooks to protect different part of the repository.
>
> > As for the rest, it's all true but our programmers have had
> this kind
> > of access to the source for the last 20 years and we've not
> had any of
> > the issues you raise. So, I'm not concerned... We do have
> a backup scheme.
> > We can go back for a year and that's served us very nicely.
>
> Just because you haven't had a problem before doesn't mean
> you won't in the future (past performance does not predict
> future results). Take this opportunity now to improve your
> processes and security. If you're going to use version
> control software, use the capabilities it offers to improve
> how you do things - don't just treat it as a glorified
> filesystem/server.
>
I agree that past performance doesn't predict future results. However,
right now I don't see svnserve or Apache as ways to improve anything.
They just add complications - granted small ones. I can tell that you
think I'm missing something fundamently important but I just don't see
it...
I'm certainly not treating our version control software (PVCS included)
as a glorified file server. I think using Subversions' branch and copy
capabilities will improve our productivity significantly.
> > > 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.
> >
> > The mere fact that svnserver or apache2 is being used does not
> > prohibit anyone from having a complete set of source code.
> Since our
> > programmers need access to the entire repository, all they
> would have
> > to do is check it out.
>
> The concern isn't about who can or can't check items out -
> that's a read-only operation. The point is protecting the
> contents of the repository from harm. Using file://, the only
> protection you have is your backups. Using an actual SVN
> server, and not a simple fileserver, you've added several
> layers of protection.
>
Let me make this perfectly clear. I don't want or need this kind of
protection. I trust our empolyees. Always have and always will. Yes
we will probably get burned eventually. If this is the best argument
for using an SVN server, I don't need one. Anything else? :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 9 13:39:25 2007