Re: svn config file and mime types

On Wed, Oct 22, 2008 at 10:35 PM, Bill Hoffman <bill.hoffman_at_kitware.com> wrote:
> I guess my main point is that this is a project decision and not an
> individual user decision. The pre-commit hook can prevent them from
> checking in stuff that we don't want in the repository. But why stop at
> prevention. Why not just do it for them? By having the pre-commit hook on
> the repository, I am saying that I will not allow files without mime types
> set. So, why make the user do extra work? Why not have a way for the
> project to define a configuration file that affects all new files in the
> project?
>

This would require access to the user's working directory and having
the user's permission to munge their files upon commit.

ClearCase does just that. When you execute a "check in" in ClearCase,
it runs the ClearCase pre-op checkin triggers (what Subversion calls
the pre-commit hook) on the user's machine and using the user's view.
Thus, in ClearCase you could write a hook (trigger in ClearCase's
parlance) to do exactly what you want -- modify the user's commit
before the commit actually takes place. If the user is suppose to
enter a defect number, you could query them. If the user needs a
special property on that file, you could do just that. If the user had
the file formatted wrong, you could correct the error during the
commit. Sounds just great!

Now, why I think that is an utterly stupid idea:

Since the hook runs on the user's system, it means that you have to
ensure that the user's system is correctly configured to run the hook.
Does the user have Python or Perl or whatever you are using installed?
Are all the correct modules needed installed? Are their directories
and mount points or network shares setup as you think they should be?
Congratulations, you now have to be responsible for making sure each
user's system is correctly configured.

Imagine a user environment of say 100 people, and an average
developer's PC lasts about four years. That means you have at least 25
percent of your users needing their systems reconfigured each year.
That means you're configuring at least one user's system every two
weeks. Don't forget new employees who get new machines (what is the
turnover in a typical development shop?) and users who suddenly have
new projects or those Windows system updates that seem to destroy your
carefully balanced environment. You could be spending 20% of your time
doing nothing but configuring users' computers.

Now, there's that guy who want to work from home. You can't configure
that system! What do you do? Tell developers they can't work from home
or over the weekend?

With Subversion's system, you only have one computer that has to be
configured to run your hook: The server. You get that working, you're
fine. Users can use any computer or any Subversion client they want.
If they made a Subversion client for the iPhone, and some goof ball
wants to use that, it's not your problem.

I was a ClearCase administrator for almost 15 years, and hooks
(triggers in ClearCase parlance) were the biggest pain because someone
always had a system where it didn't work. You did all sorts of tricks,
and checks, and sooner or later it will break. Even worse if there's
an upgrade and you're now stuck making sure all users have the upgrade
installed correctly. Plus, there's always some bozo who learns how to
get around the hooks. You can't get around a server-side hook.

I have a Subversion configuration file with the auto-properties
already configured for our project on our Wiki. This includes
installation instructions, etc. After a few failed commits because
they don't have the right properties on their files, users learn to
setup their Subversion clients to do the auto-properties. After a few
failed commits because they didn't put the defect ID in the ticket,
they learn to do it without thinking.

I don't even want the option to run hooks on client machines. It
simply causes more problems than it is worth. I like the way
Subversion handles hooks and I don't want it to change.

--
David Weintraub
qazwart_at_gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org