Yes, particularly if https://issues.apache.org/bloodhound/ticket/94
results in us clearly showing the relevant information.
Cheers,
Gary
On 05/31/2012 05:13 PM, Joachim Dreimann wrote:
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.
