I would say these extra hooks aren't something essential for the initial release. The remote repository access (that the ticket is about) is also likely to be a high priority v2 problem, because the application works well in many common use cases without it.
- Joe On 31 May 2012 17:02, Gary Martin <[email protected]> wrote: > Olemis, > > Do you mean post-commit hooks other than anything required to keep trac > informed of repository changes? > > I am wary of using commit messages to automate ticket changes, be that > comments or status changes. I think this needs some thinking through to see > if it is the best solution to automatic association of commits with > tickets. It should be noted that we should expect to already have a view of > commits against a ticket listed in the activity area. > > I am considering other options but I think what we do will have to make > sense in the context of the redesigned ticket view ( > https://svn.apache.org/repos/**asf/incubator/bloodhound/** > trunk/doc/html-templates/**ticket.html<https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/doc/html-templates/ticket.html> > ) > > Cheers, > Gary > > > > On 05/26/2012 02:37 AM, Olemis Lang wrote: > >> I second that Gary . This is a killer feature ... >> >> If you decide to enhace the plugin and if I can do something about it >> ... you can count on me . Nonetheless preliminary enlightening from >> svn experts would be very appreciated . >> ;) >> >> Another subject is how to make svn hooks work from remote . I mean >> once changeset with message "We did what we did . Close #1234" is >> committed then trigger hook @ Apache svn server to close ticket #1234 >> with context& description . Once upon a time I should have started >> >> something like this when trying to implement something similar to >> Bitbucket , Google Code , Github ... web hooks (they have different >> falvours in each case ... but essentially the same ;) . There's a >> relatively recent discussion about this subject @ trac-users ML . >> >> Anyways ... +1 for moving forward with this >> ;) >> >> On 5/25/12, Gary<[email protected]> wrote: >> >>> Hi, >>> >>> I think that this is a high priority issue from the point of view of >>> working with the >>> https://issues.apache.org/**bloodhound<https://issues.apache.org/bloodhound>site. >>> >>> Perhaps someone with superior subversion knowledge to me would like to >>> consider whether a local copy of the repository is actually feasible or >>> if there are any other obvious solutions. Otherwise, it looks like we >>> will need to look at getting a plugin working to do the job. >>> >>> Any advice on any aspect of this ticket would be extremely useful. >>> >>> Cheers, >>> Gary >>> >>> >>> On 05/25/2012 11:10 AM, Apache Bloodhound wrote: >>> >>>> #89: remote svn repository support >>>> -------------------------+----**---------------- >>>> Reporter: gjm | Owner: nobody >>>> Type: enhancement | Status: new >>>> Priority: major | Milestone: >>>> Component: siteadmin | Version: >>>> Keywords: | >>>> -------------------------+----**---------------- >>>> Trac effectively only supports a subversion repositories that are on >>>> the >>>> same server as the trac instance. More information about why this is >>>> and >>>> ways to get around this are discussed in >>>> >>>> http://trac.edgewall.org/**ticket/493<http://trac.edgewall.org/ticket/493> >>>> >>>> While using the svnsync solution may suit some systems, I am not sure >>>> if >>>> this would be feasible for >>>> https://issues.apache.org/**bloodhound<https://issues.apache.org/bloodhound>as >>>> I >>>> believe it would take a significant amount of time to perform the >>>> initial >>>> sync (unless anyone knows better of course.) >>>> >>>> It appears that the alternative plugin approach >>>> >>>> http://www.meadowy.org/~gotoh/**hg/remote-svn-plugin/<http://www.meadowy.org/~gotoh/hg/remote-svn-plugin/>has >>>> not seen any >>>> updates in a while and I don't think it will work with the various >>>> trac >>>> api changes over the years. >>>> >>>> I suspect that this feature would be useful to others and so if it can >>>> be >>>> solved, it is also likely to become a part of the Apache Bloodhound >>>> distribution. >>>> >>>> >>> >> >
