On Tue, Aug 31, 2010 at 7:11 AM, Ryan Schmidt <subversion-20...@ryandesign.com> wrote: > > On Aug 30, 2010, at 19:46, Tech Geek wrote: > >> The code that we are trying to commit is generated by an IDE - a software >> development tool. The particular file (project.xml) is usually an optional >> file that is up to the developers/user to generate. However we would like to >> enforce a policy where all the developers before they commit their changes >> make sure that the project.xml is also generated and then only a successful >> commit occurs. > > It sounds like you are saying the following: > > * There is a file project.xml that developers should have in their working > copy. > * This file does not exist in the repository because it will be different > for each developer. > * There is probably even an svn:ignore definition for project.xml.
What? Why do you assume that? Tech Geek said nothing of the kind, and that's the part that would make it impossible. > * There might be a pre-commit hook blocking anyone from committing their > project.xml. Again, what? Why do you assume that? > * You want to enforce that the developer cannot commit unless they have this > project.xml in their working copy, though it will never be sent to the > repository. It looks like Tech Geek has a trunk repository without the *.xml that he (or she) wants developers to branch, build, and commit their changes only when the build is successful and generates the *.xml file. That's.... not unusual for building release tags or regression tags. You do *not* want to tag something that doesn't even build. Mind you, auto-generating such branches or tags can overwhelm a Subversion server pretty fast. There's nothing like 3 developers generating nightly regression tags to overwhelm your "tags" folder pretty fast. > If I understand correctly, then you cannot create such an enforcement using > Subversion's server-side hook scripts. Information about the state of the > user's working copy simply is not available to the hook script for it to make > a decision based on it. Only because you've added constraints never mentioned by Tech Geek. They're conceptually reasonable for other configurations, but may not exist in this case. > If you can force your users to use a particular Subversion client, you may be > able to program something specific to that client. For example, TortoiseSVN's > client-side hook mechanism, or if you were using the command-line client, a > wrapper script around it that performs this check. And that might serve his needs if the constraints you've posited are, in fact, in place.
