|
[Issue 3096] New - Default perl script for notifying commits by email should be improved
http://subversion.tigris.org/issues/show_bug.cgi?id=3096 Issue #|3096
Summary|Default perl script for notifying commits by email sho
|uld be improved
Component|subversion
Version|1.3.x
Platform|All
URL|
OS/Version|All
Status|NEW
Status whiteboard|
Keywords|
Resolution|
Issue type|ENHANCEMENT
Priority|P3
Subcomponent|tools
Assigned to|issues@subversion
Reported by|knocte
------- Additional comments from knocte@... Thu Feb 7 05:04:18 -0800 2008 -------
Default perl script for notifying commits by email should be improved:
Currently the scheme of the content sent by mail is:
Author: {username}
Date: {date}
New Revision: {rev number}
Added:
{file1}
{file2}
Removed:
{file3}
Modified:
{file4}
Log:
{commit message}
Modified: {file4}
===================================================================
--- {file4} {date} (rev {rev number})
+++ {file4} {date} (rev {rev number})
{diff contents}
List of suggested changes:
- Log message should be shown before the summary of changes (files added,
modified, removed).
- The list of changes should be added, instead of inline, with an attachment, in
order to be able to:
a) Delete attachments in your mail client tool in order to reduce disk space usage.
b) Extract the diff file as a patch that you can commit to other branches if you
want to.
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@...
For additional commands, e-mail: issues-help@...
|
|
[Issue 3096] Default perl script for notifying commits by email should be improved
http://subversion.tigris.org/issues/show_bug.cgi?id=3096User maxb changed the following:
What |Old value |New value
================================================================================
Target milestone|--- |nonblocking
--------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@...
For additional commands, e-mail: issues-help@...
|
|
[Issue 3096] Default perl script for notifying commits by email should be improved
http://subversion.tigris.org/issues/show_bug.cgi?id=3096User knocte changed the following:
What |Old value |New value
================================================================================
Attachment data| |Created an attachment (id=
| |896)
first patch for the f
| |irst part of the issue (it
| |'s interesting to have the
| | log message first, becaus
| |e sometimes the list of ad
| |ded/modified/deleted files
| | is too big and it's diffi
| |cult to find it)
--------------------------------------------------------------------------------
------- Additional comments from knocte@... Mon Jun 9 01:57:29 -0700 2008 -------
Created an attachment (id=896)
first patch for the first part of the issue (it's interesting to have the log message first, because sometimes the list of added/modified/deleted files is too big and it's difficult to find it)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@...
For additional commands, e-mail: issues-help@...
|
|
[Issue 3096] Default perl script for notifying commits by email should be improved
|
|
Re: [Issue 3096] Default perl script for notifying commits by email should be improved
On Sat, Jun 7, 2008 at 1:42 PM, < maxb@...> wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3096>
>
>
> User maxb changed the following:
>
> What |Old value |New value
> ================================================================================
> Target milestone|--- |nonblocking
> --------------------------------------------------------------------------------
Or should we -instead- endorse mailer.py? I'm not at all that happy
with maintaining duplicate functionality. Within the Subversion core
we don't have much choice (as things stand), but do we need to do so
when the alternative is obviously so much more advanced?
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
Re: [Issue 3096] Default perl script for notifying commits by email should be improved
Erik Huelsmann wrote:
> Or should we -instead- endorse mailer.py? I'm not at all that happy
> with maintaining duplicate functionality. Within the Subversion core
> we don't have much choice (as things stand), but do we need to do so
> when the alternative is obviously so much more advanced?
I agree - why does Subversion need to provide and maintain more than one
sample post-commit mailer? It's nice to have *something* included in
the core package, but when I tried to improve commit-email.pl.in, I
found to be not very easily rewritten (no jokes about all Perl code
being that way). ;-)
We could also just mention SVN::Notify for the Perl-inclined, which is
at least as advanced and flexible as mailer.py (plus I have some
proprietary interest in that one, since I have several subclasses of it
that I have written/maintain).
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
Re: [Issue 3096] Default perl script for notifying commits by email should be improved
John Peacock wrote:
> Erik Huelsmann wrote:
>> Or should we -instead- endorse mailer.py? I'm not at all that happy
>> with maintaining duplicate functionality. Within the Subversion core
>> we don't have much choice (as things stand), but do we need to do so
>> when the alternative is obviously so much more advanced?
>
> I agree - why does Subversion need to provide and maintain more than one
> sample post-commit mailer? It's nice to have *something* included in
> the core package, but when I tried to improve commit-email.pl.in, I
> found to be not very easily rewritten (no jokes about all Perl code
> being that way). ;-)
>
> We could also just mention SVN::Notify for the Perl-inclined, which is
> at least as advanced and flexible as mailer.py (plus I have some
> proprietary interest in that one, since I have several subclasses of it
> that I have written/maintain).
Well, I'm a Python person anyway, so I'm a bit biased, but...
Yes, I would totally be happy with binning commit-email.pl and shipping
a single endorsed solution for commit emails.
Max.
|
|
Re: [Issue 3096] Default perl script for notifying commits by email should be improved
Max Bowsher wrote:
> John Peacock wrote:
>> Erik Huelsmann wrote:
>>> Or should we -instead- endorse mailer.py? I'm not at all that happy
>>> with maintaining duplicate functionality. Within the Subversion core
>>> we don't have much choice (as things stand), but do we need to do so
>>> when the alternative is obviously so much more advanced?
>> I agree - why does Subversion need to provide and maintain more than one
>> sample post-commit mailer? It's nice to have *something* included in
>> the core package, but when I tried to improve commit-email.pl.in, I
>> found to be not very easily rewritten (no jokes about all Perl code
>> being that way). ;-)
>>
>> We could also just mention SVN::Notify for the Perl-inclined, which is
>> at least as advanced and flexible as mailer.py (plus I have some
>> proprietary interest in that one, since I have several subclasses of it
>> that I have written/maintain).
>
> Well, I'm a Python person anyway, so I'm a bit biased, but...
>
> Yes, I would totally be happy with binning commit-email.pl and shipping
> a single endorsed solution for commit emails.
+1 on using mailer.py and deprecating commit-email.pl.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
Re: [Issue 3096] Default perl script for notifying commits by email should be improved
Blair Zajac < blair@...> writes:
>> Yes, I would totally be happy with binning commit-email.pl and shipping
>> a single endorsed solution for commit emails.
>
> +1 on using mailer.py and deprecating commit-email.pl.
I'm late to the party, but: +1 here too.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
Re: [Issue 3096] Default perl script for notifying commits by email should be improved
Karl Fogel wrote:
> Blair Zajac < blair@...> writes:
>>> Yes, I would totally be happy with binning commit-email.pl and shipping
>>> a single endorsed solution for commit emails.
>> +1 on using mailer.py and deprecating commit-email.pl.
>
> I'm late to the party, but: +1 here too.
The outstanding question then, is what timeline do we choose to follow
for deprecation/removal.
Given that it does _not_ use the bindings, just svnlook, the coupling to
a specific Subversion version is very loose indeed. Therefore, users of
the script will not be prevented from upgrading, if we abruptly stop
maintaining it. Therefore I'm inclined to slip a deprecation notice into
1.5.0, and plan on removing it before 1.6.
And, I've just noticed we have a commit-email.rb as well!
That one *does* use the swig bindings. I'm not sure what to suggest there.
Max.
|
|
Re: [Issue 3096] Default perl script for notifying commits by email should be improved
Max Bowsher wrote:
> Karl Fogel wrote:
>> Blair Zajac < blair@...> writes:
>>>> Yes, I would totally be happy with binning commit-email.pl and shipping
>>>> a single endorsed solution for commit emails.
>>> +1 on using mailer.py and deprecating commit-email.pl.
>> I'm late to the party, but: +1 here too.
>
> The outstanding question then, is what timeline do we choose to follow
> for deprecation/removal.
>
> Given that it does _not_ use the bindings, just svnlook, the coupling to
> a specific Subversion version is very loose indeed. Therefore, users of
> the script will not be prevented from upgrading, if we abruptly stop
> maintaining it. Therefore I'm inclined to slip a deprecation notice into
> 1.5.0, and plan on removing it before 1.6.
I'm not suggesting we remove the script since somebody may want it, just we
won't put any effort into it and we should put a large message in it saying,
please improve mailer.py instead.
> And, I've just noticed we have a commit-email.rb as well!
> That one *does* use the swig bindings. I'm not sure what to suggest there.
I don't see the bindings matter, given we work hard to maintain binary
compatibility between 1.x releases and the bindings should do the same.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
Re: [Issue 3096] Default perl script for notifying commits by email should be improved
Blair Zajac wrote:
> Max Bowsher wrote:
>> Karl Fogel wrote:
>>> Blair Zajac < blair@...> writes:
>>>>> Yes, I would totally be happy with binning commit-email.pl and
>>>>> shipping
>>>>> a single endorsed solution for commit emails.
>>>> +1 on using mailer.py and deprecating commit-email.pl.
>>> I'm late to the party, but: +1 here too.
>>
>> The outstanding question then, is what timeline do we choose to follow
>> for deprecation/removal.
>>
>> Given that it does _not_ use the bindings, just svnlook, the coupling to
>> a specific Subversion version is very loose indeed. Therefore, users of
>> the script will not be prevented from upgrading, if we abruptly stop
>> maintaining it. Therefore I'm inclined to slip a deprecation notice into
>> 1.5.0, and plan on removing it before 1.6.
>
> I'm not suggesting we remove the script since somebody may want it, just
> we won't put any effort into it and we should put a large message in it
> saying, please improve mailer.py instead.
Move it to contrib/ ?
--
C. Michael Pilato < cmpilato@...>
CollabNet <> www.collab.net <> Distributed Development On Demand
|
|
Re: [Issue 3096] Default perl script for notifying commits by email should be improved
C. Michael Pilato wrote:
> Blair Zajac wrote:
>> Max Bowsher wrote:
>>> Karl Fogel wrote:
>>>> Blair Zajac < blair@...> writes:
>>>>>> Yes, I would totally be happy with binning commit-email.pl and
>>>>>> shipping
>>>>>> a single endorsed solution for commit emails.
>>>>> +1 on using mailer.py and deprecating commit-email.pl.
>>>> I'm late to the party, but: +1 here too.
>>>
>>> The outstanding question then, is what timeline do we choose to follow
>>> for deprecation/removal.
>>>
>>> Given that it does _not_ use the bindings, just svnlook, the coupling to
>>> a specific Subversion version is very loose indeed. Therefore, users of
>>> the script will not be prevented from upgrading, if we abruptly stop
>>> maintaining it. Therefore I'm inclined to slip a deprecation notice into
>>> 1.5.0, and plan on removing it before 1.6.
>>
>> I'm not suggesting we remove the script since somebody may want it,
>> just we won't put any effort into it and we should put a large message
>> in it saying, please improve mailer.py instead.
>
> Move it to contrib/ ?
>
+1. r31755
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
[Issue 3096] Default perl script for notifying commits by email should be improved
|
signature.asc (196 bytes)