I revisit this thread to see if you can help me setting up a solution for this.
I'm going the MultiProjectCommitTicketUpdaterPlugin <https://trac-hacks.org/wiki/MultiProjectCommitTicketUpdaterPlugin> route. I've set it up like [1]. *Works:*- a commit "foo (see xxx:#99) ", adds reference to ticket 99 in project xxx *Doesn't work:1. * a commit "foo (closes xxx:#99) ", does not reference nor close ticket 99 in project xxx I've also tried: - removing the configuration commit_ticket_update in [trac] (see [2]) - removing the configuration commit_ticket_update and adding just: *commit_ticket_update_check_perms = false* Do you have any idea why tickets are not being closed? *[1] Configuration in global_trac.ini* [components] multicommitupdater.* = enabled [multicommitupdater] envelope = () commands.refs = re see rel commands.close = fix fixes fixed-forever close closes *[2] Original settings in [ticket] section* commit_ticket_update_check_perms = false commit_ticket_update_commands.close = close closed closes fix fixed fixes commit_ticket_update_commands.refs = <ALL> commit_ticket_update_envelope = () commit_ticket_update_notify = true On Wednesday, May 11, 2016 at 8:41:15 AM UTC+1, RjOllos wrote: > > > > On Tuesday, May 10, 2016 at 11:55:25 PM UTC-7, Cooke, Mark wrote: >> >> > -----Original Message----- >> > From: RjOllos [mailto:[email protected] <javascript:>] >> > Sent: 10 May 2016 20:52 >> > >> > On Tuesday, May 10, 2016 at 6:59:35 AM UTC-7, Cooke, Mark wrote: >> > >> > > Folks, >> > > >> > > I have one svn repository that is used by two Trac environments (the >> > > second created after a major re-write). Unfortunately there is some >> > > duplication of ticket numbers and I want to make sure that the >> > > commit message gets to the correct ticket. >> > > >> > > I found this thread:- >> > > >> > > https://groups.google.com/forum/#!topic/trac-users/JmePlTBHklM >> > > >> > > ...but it is not clear to me how to solve my problem. >> > > >> > > A solution that occurs to me is to use different 'envelope' >> > > characters for each Trac (e.g. "[]" or "<>") so that only one of the >> > > two tracs picks up the message, then set my post-commit hook to call >> > > both: >> > > >> > > @start trac-admin.exe D:\trac\env1 changeset added "%1" "%2" >> > > @start trac-admin.exe D:\trac\env2 changeset added "%1" "%2" >> > > >> > > (note I am on windoze here!) >> > > >> > > Can anyone suggest a better solution? >> > > >> > > Many thanks, >> > > >> > > ~ Mark C >> > > >> > >> > Using an envelope is an interesting idea. Thinking similarly, you could >> > define commit_ticket_update_commands.close and >> > commit_ticket_update_commands.refs uniquely for each environment. For >> > example, instead of the token "refs", you could define the token >> "refs:proj1" >> > or "proj1:refs". >> >> Hmm, interesting idea but we do not (yet) use the commands, only the >> references (default set to `<ALL>`). >> >> > There is also: >> > https://trac-hacks.org/wiki/MultiProjectCommitTicketUpdaterPlugin >> >> Thanks! That looks ideal (if a bit wordy!), I will have a look at the >> code. Using existing inter-Trac prefixes is consistent with "normal" usage >> >> > >> > Another possibility is to set the starting ticket number for one of the >> > environments to a large-enough value that the sequences will never >> overlap. >> >> I did not know you could do that (learn a new thing every day) >> >> > I'll be interested to hear what solution you end up going with. I could >> see >> > Trac doing something as an incremental step towards a multiproject >> > environment. >> >> At the moment we are just sending all commits to the new project but that >> is not ideal. >> >> I had another thought to replace the initial svn hook with a python >> script that can then examine the message to identify the project (e.g. by >> keyword) which would negate the need to call trac-admin twice. However >> that is more flaky as svn hooks are not backed up by default `hotcopy` and >> hides the solution outside of Trac... >> > > SVN 1.8 adds the ability to store the authz file in the/a repository. I'm > hoping it's also eventually possible to store the hook scripts in the/a > repository, but I haven't looked to see if that's on the radar of the > Subversion development team. > > https://subversion.apache.org/docs/release-notes/1.8.html#in-repo-authz > > Off-topic, but another really nice SVN 1.8 feature is the ability to > configure the hook scripts environment through a config file, which can be > shared among repositories. > https://subversion.apache.org/docs/release-notes/1.8.html#hooks-env > > - Ryan > -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
