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
Received on 2009-07-10 17:09:55 CEST