On 15 October 2013 19:33, Olemis Lang <ole...@gmail.com> wrote: > On 10/15/13, Joe Dreimann <joachim.dreim...@wandisco.com> wrote: > > > > > >> On 15 Oct 2013, at 23:03, Olemis Lang <ole...@gmail.com> wrote: > >> > >>> On 10/15/13, Ben Smithers <smithers....@googlemail.com> wrote: > >>> Olemis, > >>> > >>> As you suggested, I've created a new ticket for this: > >>> https://issues.apache.org/bloodhound/ticket/695 > >> > >> Accepted . Thanks ! > >> > >>>> No , because the repositories are global . This means that it will be > >>>> necessary to configure which product the vcs ticket updater will act > >>>> upon . > >>> > >>> > >>> You 'link' repositories to products though? > >> > >> Exactly , if a given repository is bound to several products then what > >> ticket shall be updated if commit message contains refs #1 ? > >> > >> [...] > > > > We can't update a ticket with it, at best we can provide some > disambiguation > > mechanism. > > > > Yes , you are right . > > > Only #PROD-1 can be a valid link in a multi product environment. > > > > Agreed > > > I don't believe explicitly linking repos to products explicitly to allow > #1 > > links is the correct approach. > > I've been thinking twice about it and I do not think that's an option > either . > > > Maybe optionally for migrated/merged > > environments. > > > > hmmm ... I do not think so , in those case I'd rather recommend using > RPC or alike . > > Nevertheless , I've been hesitating about whether to allow / disallow > ticket updates based on links .
It's optional already so left to the users to decide, right? > I mean , if repos R is linked to > product P1 & P2 then #P1-3 will update ticket 3 @ P1 , but #P4-8 will > be ignored with a warning (error ?) message . Is this convenient ? > Difficult to correct for user error like this. I don't think not being able to match something should be a warning or error message - just one to inform the user (ie lower priority). It's easy to fix via the web interface if a change wasn't triggered by a commit. - Joe > > -- > Regards, > > Olemis - @olemislc >
