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

[mrowe]

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?

[cboos]

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

[mgood]

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.

[cboos]

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!