The ASF does not use the vanilla mailer.py script, they are using
http://opensource.perlig.de/svnmailer - and this one does fantastic work
regarding this! We just need to change the config files of this tool and
specify a special subtree config for /lucene project folder.
See also the attached mail!
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [email protected]
> -----Original Message-----
> From: Steven A Rowe [mailto:[email protected]]
> Sent: Wednesday, November 17, 2010 7:02 AM
> To: [email protected]
> Subject: RE: mergeinfo commit mails, possible solution
>
> After looking more closely at the vanilla Subversion version of the mailer.py
> script, I'm 99% sure that removing propchange from the generate_diffs list
> will
> have zero effect, but I'd love to be proven wrong.
>
> Turns out Subversion's mailer.py once had a much larger set of property
> filtering options, but C. Mike (Pilato) thought the option set was too
> baroque, so
> he reverted the entire set - see
> <http://subversion.tigris.org/issues/show_bug.cgi?id=2944>.
>
> I've asked on #svn about re-instating the "ignore_props" and
> "ignore_propdiffs"
> regex-valued options - these would allow us to only ignore svn:mergeinfo diffs
> while still noting that files' properties have changed, without affecting
> other
> properties or their diffs. No responses yet, hopefully tomorrow.
>
> Steve
>
> > -----Original Message-----
> > From: Grant Ingersoll [mailto:[email protected]]
> > Sent: Tuesday, November 16, 2010 9:55 AM
> > To: [email protected]
> > Subject: mergeinfo commit mails, possible solution
> >
> > From #lucene IRC:
> > gsingers:sarowe and I were talking about the mergeinfo commit overload
> > [09:43]gsingers:and the asf_mailer.conf file [09:43]gsingers:In
> > looking at the file [09:44]gsingers:it appears the one thing we have
> > the ability to do is to turn off the generation of diffs for
> > [09:44]gsingers:events [09:44]gsingers:The default setting is:
> > [09:44]gsingers:generate_diffs = add copy modify propchange
> > [09:44]gsingers:sarowe and I are proposing to change our settings to
> > just be add/copy/modify [09:44]gsingers:and try dropping propchange
> > [09:45]gsingers:I honestly don't know whether it will work or not
> > [09:45]gsingers:and it will also likely mean we will miss
> > notifications of other propchanges [09:45]gsingers:We've asked on
> > #asfinfra if there are other options [09:45]gsingers:and sarowe is
> > looking into the mailer.py script to see if there are other things
> > available [09:46]gsingers:I guess the question here is, do people want
> > to try turning off propchange?
> >
> >
> > -Grant
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected] For
> > additional commands, e-mail: [email protected]
--- Begin Message ---
Hi Upayavira,
Thanks for the hint. Indeed with changing the config file (which allows
special configs for specific subtrees of the svn, so we can do it only for
Lucene), we can do it very easy:
http://opensource.perlig.de/svnmailer/doc-1.0/#groups-generate-diffs
"The generate_diffs option defines which actions diffs are generated for. It
takes a space or tab separated list of one or more of the following tokens:
add, modify, copy, delete, propchange and none.
If the add token is given and a new file is added to the repository, the
svnmailer generates a diff between an empty file and the newly added one. If
the modify token is given and the content of an already existing file is
changed, a diff between the old revision and the new revision of that file
is generated. The copy token only worries about files, that are copied and
modified during one commit. The delete token generates a diff between the
previous revision of the file and an empty file, if a file was deleted.
If the propchange token is given, the svnmailer also takes care of changes
in versioned properties. Whether it should actually generate diffs for the
property change action depends on the other tokens of the generate_diffs
list. The same rules as for files apply, except that the svnmailer never
generates property diffs for deleted files"
If we change that config option and remove propchange, then the diffs would
not contain propchanges anymore. It would it only list as modified files,
but with that we can live.
Grant: Can you send me a copy of the current config file of that tool? I
could create a patch! (I am allowed to see it).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [email protected]
> -----Original Message-----
> From: Upayavira [mailto:[email protected]]
> Sent: Tuesday, October 19, 2010 1:07 PM
> To: [email protected]
> Subject: Re: possible to filter the output to commits@ list????
>
> FWIW, the commit notices are just an SVN post-commit hook that uses the
svn-
> mailer tool [http://opensource.perlig.de/svnmailer/]. I believe Grant has
> commit rights to that file - it is in the infra SVN right next to the old
asf-auth
> file.
>
> Right now I have no idea whether svn-mailer can support the kind of
filtering
> you are talking about, but there's no harm looking!
>
> Upayavira
>
> On Tue, 19 Oct 2010 06:45 -0400, "Michael McCandless"
> <[email protected]> wrote:
> > On Mon, Oct 18, 2010 at 3:03 PM, Grant Ingersoll <[email protected]>
> > wrote:
> >
> > > It was just a bit of a shocker for me the first time I did it and I
see like 30
> files changed when I only changed one file.
> >
> > Me too. In fact I think it's ridiculous -- violates principle of
> > least surprise. I shouldn't have to see such details of the source
> > control system's impl....
> >
> > Furthermore, I think it may eventually turn into a serious perf issue,
> > since it seems to be an O(N^2) growth. We are at 7 emails today,
> > which was only 3 emails not long ago. Where will be be a few months
> > from now? (Though I guess it is bounded by the total number of source
> > files we have in 3.x...).
> >
> > Maybe svn is trying to tell us to release 4.0, heh ;)
> >
> > Mike
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected] For
> > additional commands, e-mail: [email protected]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] For additional
> commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
