add items
parent
b70169a973
commit
63dd2c1bae
|
@ -0,0 +1,16 @@
|
|||
The aggregate plugin's handling of http 401 (moved permanently) could be
|
||||
improved. Per [[rfc 1945]]:
|
||||
|
||||
> The requested resource has been assigned a new permanent URL
|
||||
> and any future references to this resource should be done
|
||||
> using that URL.
|
||||
|
||||
So ideally aggregate would notice the 401 and use the new url henceforth.
|
||||
|
||||
It's a little tricky because the aggregate plugin can't just edit the page and
|
||||
change the url in the preprocessor directive. (Because committing such an
|
||||
edit would be .. hard.) Also, aggregate directives may also include a separate
|
||||
url for the site, which may also have changed. Perhaps the thing to do is
|
||||
record the new url in the aggregate plugin's state file, and change the message
|
||||
to "Processed ok (new url http://..)", and let the user deal with updating
|
||||
the page later.
|
|
@ -0,0 +1,17 @@
|
|||
It would be good to be able to exclude commits made by a given user from
|
||||
generating commit mails.
|
||||
|
||||
My immediate need for this is because I subscribed to commit mails using my
|
||||
openid. So I don't get commit mails for changes I make over the web, using
|
||||
that id. But, if I do a svn commit, that's from a "different" user, so a
|
||||
commit mail is sent to me. This particular case could be treated as ikiwiki
|
||||
needing some way to link together openids and other accounts, which could
|
||||
also be good, but I think the general case of not wanting to see changes
|
||||
some other user makes is reasonable.
|
||||
|
||||
Extending pagespecs for commit mails would be a nice approach. Then I could
|
||||
subscribe to:
|
||||
|
||||
* and !SandBox and !user(joey)
|
||||
|
||||
Insert standard argument about how wonderfly flexible this is. :-)
|
Loading…
Reference in New Issue