On Fri, May 16, 2008 at 9:45 AM, James Ralston <
qralston+ml.svn-users_at_andrew.cmu.edu<qralston%2Bml.svn-users_at_andrew.cmu.edu>>
wrote:
> We use Subversion to maintain a repository that consists of various
> configuration files in various directories.
>
> The repository has a post-commit hook script. When the post-commit
> hook script fires, it checks out the latest version of the repository
> and scans the structure and the configuration files for syntax errors.
> If it finds errors, it sends a mail message to the person who
> committed the revision; if no errors are found, it pushes out the
> configuration files to other systems as appropriate.
>
> It would be highly desirable to be able to perform the syntax-checking
> in the pre-commit hook script, for the following reasons:
>
> 1. The commits made to the repository are often time-sensitive;
> having to wait until a mail message shows up to tell if
> something went wrong is often highly undesirable.
>
> 2. Since success is the norm, the people performing the commits
> often don't bother to check their email to see if they
> received a notification of a syntax error.
>
> If the syntax checking occurred in the pre-commit hook script, I could
> abort the commit if an error were found, and return a useful message
> to the person attempting to make the commit.
>
> The problem, however, is that in order to perform the syntax checking
> in the pre-commit hook script, I need to obtain a copy of what the
> repository would look like if the commit were to occur successfully.
> In other words, I need to be able to run "svn checkout" on the
> transaction ID of the commit.
>
> Unfortunately, the "checkout" command doesn't have this ability. And
> although it would be theoretically possible to emulate "svn checkout"
> on a transaction ID by using svnlook tree/cat, that would be
> incredibly inefficient, and extremely difficult to code correctly.
>
> Therefore, my feature request is this: it would be *incredibly* useful
> to have some equivalent to "svn checkout" that could be run on a
> transaction ID within a pre-commit hook script, that would
> *efficiently* give you a copy of what will become the latest revision
> of the repository should the commit transaction succeed. It doesn't
> have to be a working copy in the "svn checkout" sense; it just needs
> to have the structure (the directories/files) there.
>
> Thoughts?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
I'm just thinking, but the pre-commit hooks have access (to at least) the
new version of the changed files. Why couldn't you svn co (or svn export)
the base revision, write the new file contents, then run your checks?
If you keep the temp area a working copy, you can 'svn update' to the target
path/revision and use svn revert to revert it to it's original state when
done.
Received on 2008-05-16 21:05:32 CEST