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.
> 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.
> > 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 9 02:59:50 2007