[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Report mergeinfo-only changes less verbosely [was: [RFC] *Greatly* improve merge performance...]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 10 Jul 2009 15:31:47 +0100

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

Received on 2009-07-10 16:32:13 CEST

This is an archived mail posted to the Subversion Dev mailing list.