Allow Trac to send commit information email when the " sync "with the repository

[utopiste]

Lot of people send diff by email (or create a commit mailing list) for per review.

Currently trac have a excellent diff display, html generator, a good notify class and a sync command to trac-admin.

With all that it's easy to add a option for sending commit information by email (with some IniFile option)

the only thing add will be a trac-admin … sync in the post-commit hook

[walterjwhite@…]

Hi,

I had an idea (not sure if it got implemented) about repository access across the web. The server that I have setup has the working copies on the server itself. This is so the webpages can be rolled back to a different version. For people that do not have shell access to the server, they cannot update/commit changes from this working space to the repository and vice versa. Right now, they have a local working space which resides on their machine. The problem lies in that they cannot version their webpages efficiently. The process right now is commit changes to the server, then upload the files to the server which requires a subversion client to be installed. By adding working space functionsin trac, the user can work on the files more directly and quickly (no software needs to be installed), only a commit is required to version the files, and rolling back to prior versions also removes additional complexity. I think that idea is good too as there are teams that work individually some times and that would also help to increase their efficiency.

Walter

[Mark Rowe]

I think that generating commit emails is a little outside of Trac's scope. Subversion provides several post-commit scripts that have this functionality so I'm unsure as to why it belongs in Trac?

[Christian Boos]

This could be considered as part of a more generic notification infrastructure (notify on Web page changes, new changesets, etc.)

[Matthew Good]

We can add another "listener" interface for changesets that will be called when and new changeset is found. The automated closing of tickets done by the current "contrib" post-commit hook could also be handled by this interface.

[Christian Boos]

Replying to mgood:

We can add another "listener" interface for changesets that will be called when and new changeset is found.

Well, I have nothing against, but I just wanted to point out that in the longer run, I prefer that we adopt a more "generic" IResourceChanged interface (with (type,id) info + generic authorship info).

The automated closing of tickets done by the current "contrib" post-commit hook could also be handled by this interface.

… and therefore get rid of all those encoding issues we're seeing with the hook. Good idea!

[anatoly techtonik <techtonik@…>]

I wonder if there any Trac hacks for this?

[Remy Blank]

I don't know about plugins, but the multirepos​ branch has the IRepositoryChangeListener interface mentioned in comment:5, so this can now relatively easily be done in a plugin.

[anatoly techtonik <techtonik@…>]

With that IRepositoryChangeListener if I need to resync revisions from scratch - will I receive tons of emails about them?

[Remy Blank]

Replying to anatoly techtonik <techtonik@…>:

With that IRepositoryChangeListener if I need to resync revisions from scratch - will I receive tons of emails about them?

No, the events are not triggered by a resync, but by explicit trac-admin $ENV changeset added and trac-admin $ENV changeset modified commands that must be called from e.g. SVN hooks.

[Remy Blank]

Bordering on "wontfix" (or rather "shouldbedoneinaplugin") now that IRepositoryChangeListener is available.

[Joongi Kim <me@…>]

As a multiple-repository user, I would like to integrate all notifications into the single Trac, rather than adding post-commit hooks for each repository, particularly when I have to manage heterogeneous types of repositories which have different methods for configuration of hooks.

We could implement this as a plugin, but I think we need one more consideration —- the notification of ticket comments by CommitTicketUpdater and the changeset listener should NOT be duplicated. So we might have to modify the official CommitTicketUpdater plugin.

Currently I'm getting notification emails like:

#XX: blah blah
----------------------------+--------------------
 Reporter:  joongi         |      Owner:  joongi
     Type:  enhancement    |     Status:  new
 Priority:  trivial        |  Milestone:
 Component:  Documentation  |    Version:
Resolution:                 |   Keywords:
----------------------------+--------------------

Comment (by joongi):

 In [XXX]:
 {{{
 #!CommitTicketReference repository="YYY" revision="XXX"
 refs #XX: blah blah
 }}}

I want to see actual diffs for the revision.