On Tuesday, May 10, 2016 at 11:55:25 PM UTC-7, Cooke, Mark wrote: > > > -----Original Message----- > > From: RjOllos [mailto:[email protected]] > > 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.
