Re: Subversion - Hook

On Thu, Jan 13, 2011 at 7:31 AM, Vipin B <vipin.b_at_tcs.com> wrote:
> Dear Sir/Madam,

I hope you realize that this isn't a support department from some
company, but a mailing filled with lots of "Sirs" and "Madams".
Basically, we're just a bunch of Subversion users who support each
other.

>  There is a specific requirement in our project that the tags used in JSP should be
> same(Case-Sensitive) as defined in  struts-tags.tld file. E.g. If we use <Input> tag with capital 'i',
> our weblogic server will run that JSP page but in  Struts-tags.tld file this tag is defined as
> <input> with small 'i'. I want to develop a SVN pre-commit hook to avoid such ambiguity. User
> should able to commit the file only when he/she is using <input> with small 'i' only as it is
>  mentioned in .tld file.

So, what you want to do is prevent a user from committing a JSP file
unless the tld file contains the same tags? I am not aware of a
current pre-commit hook that can do this. However, it is possible to
write such a pre-commit hook. There are several issues involved:

* Where do the tags come from? Is there a predefined list, or before a
JSP is committed, the hook needs to read one or more tld files and
verify all the tags are the same as in that file.

* What if the user commits a new tld file? Should the reverse take
place? Do you need the pre-commit hook to go through all the JSP files
and make sure the tags match?

* What if a user commits both a tld and JSP file? The pre-commit hook
needs to verify both.

I don't believe such a hook currently exists, but it shouldn't take
too long to produce such a hook (a couple of weeks at the most). You
may have to hire someone to do it for you. There are many people on
this list who do such things for a living and maybe someone here will
be willing to take on this task as a job.

In my humble professional opinion, things like this can easily be
caught with a continuous build process. Remember that version control
systems are made, so you can easily back out mistakes, so if you can
catch stuff like this at build time (along with other issues that may
crop up), you are still in good shape. I am not fond of pre-commit
hook scripts that try to parse code since they can easily take way too
much time checking for problems, and usually end up marking something
as wrong when it is okay.

However, this really shouldn't have to come down to a pre-commit hook
policy. These are Java Server Pages. Every developer should be running
their own test server. Tomcat is open source, so there isn't a license
issue. You don't have to compile anything. You don't even have to drop
the server or bounce it -- just replace the page and see how it
performs. Any issues would be on the JSP page that was changed and
won't have side effects throughout the application. Basically, your
developers should be catching this before they even think of
committing their changes.

Your developers need to be in the habit of testing any changes before
committing them to the project. If your developers aren't thoroughly
testing their code before they commit their changes, no number of
pre-commit hooks will help.

-- 
David Weintraub
qazwart_at_gmail.com