martinay <firstname.lastname@example.org> writes:
> Hi Ben !
> Thanks for your hint ! I will try to make it work, but you probably know
> that developpers are sometime lazy ... :-)
> How can I make sure that devs are issuing an "svn ps bugid NNN [PATH]" with
> the same path as choosen while issuing the "svn commit [PATH]" ? probably it
> won't be as problem most of the time, but just to enforce it ...
> I thought it would me nice to have something in-between with unversioned
> props, but I can figured out how to apply it to "future commits", it would
> be nice to have something without path related, but only assigned to
> revision (but "future" revision) so command will look like :
> svn ps bugid --revprop -r PENDING NNN
> (currently, --revprop can only be assigned to revision from the past (not to
> PENDING revision), which is my bottleneck. Devs can assigned versionned
> props during their works, but than they are force to modify files outside
> the previous scope, and when they try to commit, the trigger will need to
> make that all files are included in the new scope)
> That why I was trying to get the "bugid" attached with the commit itself.
> Maybe there is a good compromise ? Any idea to get it even smooter ?
Were I you, I would write a pre-commit hook in Python that uses the
Subversion Python bindings to do this:
1. Read the 'svn:log' property on the transaction that's about to
be committed, looking for some regular expression like "issue
1300" -- whatever format you want your bugid's referenced as.
2. If that bugid is found, set a 'bugid' property on the
transaction -- this will be automatically promoted to a revision
property when the commit succeeds. If, however, no bugid is
found in the committer's log message, return non-zero and cause
the commit to fail (you could even have the script send email to
the developer saying that he forgot to put the bugid in his
commit log message).
Unlike setting versioned path properties, setting revision properties
is safe to do from within the pre-commit hook because the working copy
doesn't have to stay in sync with that value.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu May 22 05:24:26 2003