Opened 17 years ago
Closed 16 years ago
#7019 closed enhancement (wontfix)
Add the ability to show full changset diff in RSS
Reported by: | Owned by: | Emmanuel Blot | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | notification | Version: | |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
It's currently possible to have an RSS feed for each changeset, but in order to see the contents of the changeset one has to follow a link. What I'd like to do is have the full diff available through the RSS feed. This would replace the more traditional method of pushing out commit emails with a per-user pull method.
Attachments (0)
Change History (5)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
If it's configurable, I guess I don't see where much of the problem is. As of now, the feed entries are largely useless to me. That of course doesn't mean that they aren't useful to others.
What I'm advocating is leaving the existing short feeds as the default, but allowing the full feeds through some configuration parameter.
Not being familiar with the Trac codebase, if this would not be implemented in core, how would one go about it? Can plugins hook into the RSS generation mechanism?
comment:3 by , 17 years ago
You need the ability to add extra download formats to the TracRevisionLog, something I'm not sure you can do for now, but this will be there for the next release (0.12 - #3332).
comment:4 by , 16 years ago
I was thinking along slightly different lines: show the files edited (the same list as the linked changeset page shows) within the content of the RSS item. For large projects, it's not always obvious from the changeset message what part of the project is actually affected; listing the files affected would somewhat help (and might give a partial solution to this ticket).
I've no idea what the performance penalty would be though :|
comment:5 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I don't see this in Trac core either.
That could probably be OK for small repositories, with not that many changes and users. Otherwise the additional load generated by such a feature would be too high.
I don't see this implemented in Trac core.