> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: Tuesday, January 09, 2007 8:58 AM
> To: Brian Erickson
> Cc: Ryan Schmidt; users@subversion.tigris.org
> Subject: Re: Re: Configuration files...
>
> On 1/9/07, Brian Erickson <erickson@bauercontrols.com> wrote:
> >
> >
> > > -----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.
>
> The more-common (and accepted, in multiple-user setups) is to
> use hooks to *augment* the built-in access controls built
> into svnserve and mod_dav_svn. If you were to use an actual
> SVN server, you might be able to avoid the hooks for security
> altogether.
>
> > >
> > > > 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...
>
> > 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? :)
>
> Do you ever get audited? Got any ISO standards you need to
> meet, industry requirements, CMM, anything like that?
>
Yes, the file:// syntax provides everything we need.
> Might you ever need to offer access to the repository to
> people who don't have access to the fileserver?
>
No.
> Might you want to make portions of the repository available
> to people via a simple, read-only interface instead of having
> to use a Subversion client and full working copy?
>
No.
> By using file:// access, *ANYONE* can delete the whole
> repository with a single errant keystroke. This isn't even
> about "trust", it's about mistakes. Stuff happens. Using
> svnserve or Apache, it's possible to delete the contents, but
> because it's a versioned operation, it's just as simple to
> undo the delete as it is to do the delete.
>
I don't know, maybe we're just more careful than the rest of the world.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 9 15:30:37 2007