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 ?
(BTW, such exercise remind me something interesting about "commit" features
: I've seen some products offering not only "PENDING" ChangeSet, but also
user-defined changesets for which Devs can assigned files been modfied to
specific changeset (which corresponding to specific bugid), so I don't known
how we can expand capabilites on that side, but it would be nice to have
such "changeset" pendings with associated props)
> martinay <firstname.lastname@example.org> writes:
> > The goal I wish to achieve :
> > - using the simple "svn" command line, I want to provide
> some "external
> > arguments" to hook to our BugTracker, so that each time
> someone checkin
> > something, some infos will be added to BugTracker's DB using the the
> > "pre-commit" and "post-commit" script ...
> > What I've discovered :
> > - It seems that an "svn commit" command didn't provide any "external
> > arguments" accessible by the trigger scripts.
> No, the pre-commit and post-commit hook scripts receive only fixed
> arguments. It's assumed that you can use 'svnlook' or other tools to
> examine the stuff that is committed.
> What kind of "external arguments" do the hook scripts need to pass to
> your bug tracker? If it's metadata about the commit, perhaps it could
> come out of a file or directory property?
> For example, require that users set a specific 'bug-number' property
> when they commit (enforced by the pre-commit hook script). Then the
> post-commit hook script can look for the property.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu May 22 04:45:46 2003