On Thu, Jan 13, 2011 at 7:31 AM, Vipin B <vipi...@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 qazw...@gmail.com
