On Fri, Jul 10, 2009 at 8:09 AM, Geoff Rowell<geoff.rowell_at_varolii.com> wrote:
> Julian Foad wrote:
>> Geoff Rowell wrote:
>> > Aside from performance, I wouldn't have such a problem with
>> > mergeinfo if it didn't tend to alarm my users. They try to merge a
>> > 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,
>> our "svn" CLI and GUIs like TortoiseSvn, should help the user to see
>> 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
>> to those.
>> Worth doing?
>> Where are the other places that should have this
> 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.
glasser_at_davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
Received on 2009-07-10 20:24:31 CEST