You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2009/07/10 14:31:47 UTC
Report mergeinfo-only changes less verbosely [was: [RFC] *Greatly*
improve merge performance...]
Geoff Rowell wrote:
> Aside from performance, I wouldn't have such a problem with distributed
> mergeinfo if it didn't tend to alarm my users. They try to merge a few
> files and Subversion reports a massive number of changes.
>
> A serious review of where and when mergeinfo property changes are
> reported is needed.
We talked once about hiding mergeinfo-only changes from the user, and
that was rightly rejected. Did we talk about "sidelining" or
"summarising" their display?
It seems clear now, with hindsight and lots of mergeinfo, that UIs, both
our "svn" CLI and GUIs like TortoiseSvn, should help the user to see the
significant changes without the clutter of mergeinfo-only changes.
"svn status" could by default summarize all the mergeinfo-only changes
in one line at the end:
[[[
$ svn status
M myfile
M dir/myfile2
43 items with changes to mergeinfo are also present but not shown.
]]]
"svn commit" when generating a log message could list them separately:
[[[
--This line, and those below, will be ignored--
M myfile
MM dir/myfile2
The following items have only mergeinfo changes:
M .
M file1
M dir
M dir/file4
M dir/file5
M dir/file6
...
M dir/file43
]]]
This would require modifications to the "status" and "commit"
notification methods, of course. And there are command-line
compatibility questions, but it's not a big deal to decide on a solution
to those.
Worth doing?
Where are the other places that should have this separation/summarising?
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369736
Re: Report mergeinfo-only changes less verbosely [was: [RFC]
*Greatly* improve merge performance...]
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
> -------Original Message-------
> From: Julian Foad <ju...@btopenworld.com>
> Subject: Report mergeinfo-only changes less verbosely [was: [RFC] *Greatly* improve merge performance...]
> Sent: 10 Jul '09 07:31
>
> Geoff Rowell wrote:
> > Aside from performance, I wouldn't have such a problem with distributed
> > mergeinfo if it didn't tend to alarm my users. They try to merge a few
> > files and Subversion reports a massive number of changes.
> >
> > A serious review of where and when mergeinfo property changes are
> > reported is needed.
>
> We talked once about hiding mergeinfo-only changes from the user, and
> that was rightly rejected. Did we talk about "sidelining" or
> "summarising" their display?
>
> It seems clear now, with hindsight and lots of mergeinfo, that UIs, both
> our "svn" CLI and GUIs like TortoiseSvn, should help the user to see the
> significant changes without the clutter of mergeinfo-only changes.
>
> "svn status" could by default summarize all the mergeinfo-only changes
> in one line at the end:
>
> [[[
> $ svn status
> M myfile
> M dir/myfile2
> 43 items with changes to mergeinfo are also present but not shown.
> ]]]
>
> "svn commit" when generating a log message could list them separately:
>
> [[[
>
> --This line, and those below, will be ignored--
>
> M myfile
> MM dir/myfile2
>
> The following items have only mergeinfo changes:
> M .
> M file1
> M dir
> M dir/file4
> M dir/file5
> M dir/file6
> ...
> M dir/file43
> ]]]
>
> This would require modifications to the "status" and "commit"
> notification methods, of course. And there are command-line
> compatibility questions, but it's not a big deal to decide on a solution
> to those.
I started hacking some of these ideas several months ago on the ignore-mergeinfo branch. I did some client-side filtering, but stopped short of extending this to the repository APIs. It could be done, though. Feel free to use the branch if you want to start working on this idea.
> Worth doing?
>
> Where are the other places that should have this separation/summarising?
>
> - Julian
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369736
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2371537
Re: confidential mails -- was: Re: Report mergeinfo-only changes
less verbosely [was: [RFC] *Greatly*improve merge performance...]
Posted by Erik Huelsmann <eh...@gmail.com>.
On Tue, Jul 21, 2009 at 10:17 PM, Stefan Sperling<st...@elego.de> wrote:
> On Tue, Jul 21, 2009 at 03:55:19PM +0200, Neels Janosch Hofmeyr wrote:
>> > This email and any files transmitted with it are confidential and intended
>> > solely for the use of the individual or entity to whom they are addressed.
>> > If you have received this email in error please notify the sender.
>>
>> Consider yourself notified.
>>
>> I've seen this before and the answer was "yes, sorry, it's company policy,
>> can't get rid of it." It bugs me nevertheless.
>
> See also http://producingoss.com/en/communications.html#face
>
>> It seems to me that, with a mail footer like this, your company policy is
>> incompatible with contributing to dev@ discussions, which should be
>> addressed. A private mail account could be used, for example.
>
> Some companies lock their people in so much that they can't even
> get at other mail at work...
In which case they're probably not meant to communicate outside the
company. I suggest they do not do so, or revert contributions to this
group to their evenings where they hopefully do have the rights to log
in to hotmail, yahoo or gmail.
Bye,
Erik.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2374399
Re: confidential mails -- was: Re: Report mergeinfo-only changes
less verbosely [was: [RFC] *Greatly*improve merge performance...]
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jul 21, 2009 at 03:55:19PM +0200, Neels Janosch Hofmeyr wrote:
> > This email and any files transmitted with it are confidential and intended
> > solely for the use of the individual or entity to whom they are addressed.
> > If you have received this email in error please notify the sender.
>
> Consider yourself notified.
>
> I've seen this before and the answer was "yes, sorry, it's company policy,
> can't get rid of it." It bugs me nevertheless.
See also http://producingoss.com/en/communications.html#face
> It seems to me that, with a mail footer like this, your company policy is
> incompatible with contributing to dev@ discussions, which should be
> addressed. A private mail account could be used, for example.
Some companies lock their people in so much that they can't even
get at other mail at work...
Stefan
confidential mails -- was: Re: Report mergeinfo-only changes less
verbosely [was: [RFC] *Greatly*improve merge performance...]
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Sorry if I'm interrupting "important stuff", but sending this to an
open-source mailing list simply makes absolutely no sense at all:
Geoff Rowell wrote:
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369778
Consider yourself notified.
I've seen this before and the answer was "yes, sorry, it's company policy,
can't get rid of it." It bugs me nevertheless.
It seems to me that, with a mail footer like this, your company policy is
incompatible with contributing to dev@ discussions, which should be
addressed. A private mail account could be used, for example.
Couldn't this actually be causing a legal nightmare at some point?
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372981
Re: Report mergeinfo-only changes less verbosely [was: [RFC]
*Greatly*improve merge performance...]
Posted by David Glasser <gl...@davidglasser.net>.
On Fri, Jul 10, 2009 at 8:09 AM, Geoff Rowell<ge...@varolii.com> wrote:
> Julian Foad wrote:
>> Geoff Rowell wrote:
>> > Aside from performance, I wouldn't have such a problem with
> distributed
>> > mergeinfo if it didn't tend to alarm my users. They try to merge a
> few
>> > files and Subversion reports a massive number of changes.
>> >
>> > A serious review of where and when mergeinfo property changes are
>> > reported is needed.
>>
>> We talked once about hiding mergeinfo-only changes from the user, and
>> that was rightly rejected. Did we talk about "sidelining" or
>> "summarising" their display?
>>
>> It seems clear now, with hindsight and lots of mergeinfo, that UIs,
> both
>> our "svn" CLI and GUIs like TortoiseSvn, should help the user to see
> the
>> significant changes without the clutter of mergeinfo-only changes.
>>
>> "svn status" could by default summarize all the mergeinfo-only changes
>> in one line at the end:
>>
>> [[[
>> $ svn status
>> M myfile
>> M dir/myfile2
>> 43 items with changes to mergeinfo are also present but not shown.
>> ]]]
>>
>> "svn commit" when generating a log message could list them separately:
>>
>> [[[
>>
>> --This line, and those below, will be ignored--
>>
>> M myfile
>> MM dir/myfile2
>>
>> The following items have only mergeinfo changes:
>> M .
>> M file1
>> M dir
>> M dir/file4
>> M dir/file5
>> M dir/file6
>> ...
>> M dir/file43
>> ]]]
>>
>> This would require modifications to the "status" and "commit"
>> notification methods, of course. And there are command-line
>> compatibility questions, but it's not a big deal to decide on a
> solution
>> to those.
>>
>> Worth doing?
>>
>> Where are the other places that should have this
> separation/summarising?
>>
>
> I'd also suggest modifying the output of "svn log -v".
That was my first thought as well. That does ~require a repository
format change, though.
--dave
--
glasser@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369944
RE: Report mergeinfo-only changes less verbosely [was: [RFC]
*Greatly*improve merge performance...]
Posted by Geoff Rowell <ge...@varolii.com>.
Julian Foad wrote:
> Geoff Rowell wrote:
> > Aside from performance, I wouldn't have such a problem with
distributed
> > mergeinfo if it didn't tend to alarm my users. They try to merge a
few
> > files and Subversion reports a massive number of changes.
> >
> > A serious review of where and when mergeinfo property changes are
> > reported is needed.
>
> We talked once about hiding mergeinfo-only changes from the user, and
> that was rightly rejected. Did we talk about "sidelining" or
> "summarising" their display?
>
> It seems clear now, with hindsight and lots of mergeinfo, that UIs,
both
> our "svn" CLI and GUIs like TortoiseSvn, should help the user to see
the
> significant changes without the clutter of mergeinfo-only changes.
>
> "svn status" could by default summarize all the mergeinfo-only changes
> in one line at the end:
>
> [[[
> $ svn status
> M myfile
> M dir/myfile2
> 43 items with changes to mergeinfo are also present but not shown.
> ]]]
>
> "svn commit" when generating a log message could list them separately:
>
> [[[
>
> --This line, and those below, will be ignored--
>
> M myfile
> MM dir/myfile2
>
> The following items have only mergeinfo changes:
> M .
> M file1
> M dir
> M dir/file4
> M dir/file5
> M dir/file6
> ...
> M dir/file43
> ]]]
>
> This would require modifications to the "status" and "commit"
> notification methods, of course. And there are command-line
> compatibility questions, but it's not a big deal to decide on a
solution
> to those.
>
> Worth doing?
>
> Where are the other places that should have this
separation/summarising?
>
I'd also suggest modifying the output of "svn log -v".
-Geoff
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369778