Hi Daniel,
I already proposed something similar to our developers list and also
explained, why it is a bad idea to merge single files (see attached mail).
Still our/my opinion: It may be better, to simply provide optionally "plain"
diffs without metadata for commit mails (on request of a project, e.g. Grant
Ingersoll could configure that for the Lucene project in the SVN config
file).
Uwe
-----
Uwe Schindler
uschind...@apache.org
Apache Lucene PMC Member / Committer
Bremen, Germany
http://lucene.apache.org/
> -----Original Message-----
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: Sunday, October 17, 2010 5:17 PM
> To: Uwe Schindler
> Cc: dev@lucene.apache.org; 'Apache Infrastructure'
> Subject: Re: possible to filter the output to commits@ list????
>
> Or you could try to see if some of the existing mergeinfo can be removed,
and
> try to have less subtree mergeinfo in the first place; these are common
topics
> on us...@subversion.
>
> Uwe Schindler wrote on Sun, Oct 17, 2010 at 17:06:44 +0200:
> > Hi all,
> >
> > There are configuration options in SVN to let the commit mails pipe
through a
> filter. Other svn hosting providers like Sourceforge provide some filters
to be
> applied. Ideally, you would use the "patchutils" package (it's called like
this in
> Debian/Ubuntu) and use "svn diff | filterdiff --clean" and pipe that into
an
> eMail. Maybe we should open an issue at infra?
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > uschind...@apache.org
> > Apache Lucene PMC Member / Committer
> > Bremen, Germany
> > http://lucene.apache.org/
> >
> > > -----Original Message-----
> > > From: Robert Muir [mailto:rcm...@gmail.com]
> > > Sent: Sunday, October 17, 2010 4:58 PM
> > > To: dev@lucene.apache.org
> > > Subject: possible to filter the output to commits@ list????
> > >
> > > Lets say i change a single line of code, and merge it back to the
3x_branch.
> > >
> > > Currently we get 6 or 7 emails of mergeproperty changes to the
> > > commits@ list... this is making it difficult or impossible for
> > > backports to be reviewed at all... I think this is terrible.
> > >
> > > How can we get this fixed so that these mergeprop-changes only are
> > > filtered in the emails? Someone could always click the link to
> > > viewvc or whatever if they are interested in this...
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > > additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
--- Begin Message ---
I cc'ed my previous eMail also to the in...@ao list. In general, if we cannot
filter we could think about the following:
- remove all mergepros recursively for trunk, but we would lose history for
merges.
- Alternatively merge all mergeprops up to the root folder and remove it from
the separate files/subfolders. This would lose some changes, but if all are
merged up, that’s fine (only some files may appear as merged from different
branch, although they aren't).
In general when merging to reduce the amount of mergeprops:
- Don't merge single files or subdirectories! Always merge the top folder!
Excluded from this is trunk/modules, as this needs a separate, merging step
between trunk/3x. So a merge would then only add mergeprops to root folder and
modules/contrib (in branch).
This is the explanation for the behavior:
SVN needs to add the mergeprops to all single files that *already* contain
mergeprops on each merge (SVN is not able to only store "diffs" in per file
props). This is the reason why we have so many mergeprops at single files that
every time gets updated: Once a file has a merge property, it does no longer
inherit it from the parent folder. Whenever you merge something, the new rev
numbers get added to the parent folder, as expected; but as this single file
also have mergeprops and those are not differential/separate to parent, the
merge prop of this single file also needs to be updated. This leads to the
large modification email. We cannot change that anymore, so by reducing the
number of single-file merges, we can stop this behavior from getting worse. To
get rid of it completely and start new, see above.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -----Original Message-----
> From: Robert Muir [mailto:rcm...@gmail.com]
> Sent: Sunday, October 17, 2010 4:58 PM
> To: dev@lucene.apache.org
> Subject: possible to filter the output to commits@ list????
>
> Lets say i change a single line of code, and merge it back to the 3x_branch.
>
> Currently we get 6 or 7 emails of mergeproperty changes to the commits@
> list... this is making it difficult or impossible for backports to be
> reviewed at
> all... I think this is terrible.
>
> How can we get this fixed so that these mergeprop-changes only are filtered in
> the emails? Someone could always click the link to viewvc or whatever if they
> are interested in this...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
