On Sat, Nov 29, 2003 at 10:53:22PM -0600, Ben Collins-Sussman wrote:
> > Isn't what the OP is asking for simply the Aegis-like feature of
> > having a pre-commit "hook"? I perhaps tried to read too much into the
> > posting, but I got the impression he simply wanted a way to be able to
> > have his own pre-commit hook execute and be able to "do its thing" and
> > then return a success/failure result that the commit command would
> > then abort/proceed based upon its status.
>
> Sure... but how would you design a "pre-commit hook" to
>
> 1) verify that a unit-test was committed with the change
> 2) verify that the unit-test passes
That my (or the OPs) problem to solve. All I need Subversion
to do is give me the hook. The rest is up to me. There is no
need/requirement for any long-lived transaction here. Whether
it is trivial or not is entirely up to me and how I choose to
enforce it. I've seen this sort of thing solved with extremely
sophisticated and complex mechanisms that implement additional
workflow and nested transactions.
I've also seen this sort of thing implemented with extremely
simple formatting in a single text file and some source tree
standards for where a set of tests should go and how they
should be named and how to know which tests correspond to which
"files" or modules, and where to write the results so that a
pre-commit-hook can check all of it without a ton of effort
(most of the "effort" is in getting the team to agree to
the standards/conventions) so that the pre-commit hook can:
- Look at the set of files in the to-be-committed change-set
- Compute the set of corresponding test-file names using the standard
- Use the naming convention to map class/method/model/whatever
names to corresponding test names/numbers and make sure they are there
- Run the tests and/or look for the test-results as "published"
in some text file in a known location
- If desired look for a manager "signoff" using whatever desired
mechanism (MD5, or whatever) or even use a "property" of some
sort and check the history/event logs to verify the right
manager or "group" signed off (or what have you)
It aint perfect, but its "good enough" and its simple enough. If it
fails, I can write the failure reason to a known file, even write
some "status/state" info and generate some email or talk to my
tracking-tool to fire off a signoff workflow, or simply consult the
tracking tool for the signoff and look for the corresponding state
there.
Whatever I do, that is of course up to me. I just need the pre-commit
hook and the failure/success return. There is no need to assume a
broader requirement for long-lived transactions or nested transactions
or any of that stuff. Not that those aren't nice to have for other
reasons of course - but I don't see those being asked for here. All
thats being asked for is a way to get assistance from subversion
in enforcing a process, and all thats needed is the "hook" between
however I choose to implement it myself and the commit-operation.
--
Brad Appleton <brad@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 1 06:48:53 2003