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

Re: issue 3342 - summary of conflicts and skips [was: ... 3432 ...]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 30 Jul 2009 17:59:23 +0100

Hi Daniel.

Thanks for your interest.

Issue #3342 <http://subversion.tigris.org/issues/show_bug.cgi?id=3342>
is not talking about the "G foo1" notifications. It is about the message
that says

[[[
Summary of conflicts:
  Text conflicts: 2
  Property conflicts: 1
  Skipped paths: 10
]]]

Sorry - that's my fault for not being clear when I wrote it. I've just
added a note to the issue to clarify this.

To fix this, I would change the notifier function in
subversion/svn/notify.c so that it still collects the statistics in
'nb->text_conflicts' etc., but does NOT call print_conflict_stats() when
it gets an 'update_completed' or 'merge_completed' notification.
Instead, make print_conflict_stats() a public function (named
svn_cl__print_conflict_stats()) so that the top-level update function
(svn_cl__update()) can call it to print the stats when the whole update
is finished.

Then adjust the callers (update, switch and merge) to call
svn_cl__print_conflict_stats() after finishing the update/switch/merge
operation.

Does that make sense?

- Julian

Daniel Näslund wrote:
> If I do an update s summary is printed. If there are conflicts a summary
> for each file is printed after each interactive operation. If many
> files, the summary may scroll off the screen. An example:
>
> test2> s up
> Conflict discovered in 'foo1'.
> Select: (p) postpone, (df) diff-full, (e) edit,
> (mc) mine-conflict, (tc) theirs-conflict,
> (s) show all options: mc
> G foo1
> Conflict discovered in 'foo2'.
> Select: (p) postpone, (df) diff-full, (e) edit,
> (mc) mine-conflict, (tc) theirs-conflict,
> (s) show all options: mc
> G foo2
> Updated to revision 2.
>
> Better would be to have this printed at the bottom:
> Conflict discovered in 'foo1'.
> Select: (p) postpone, (df) diff-full, (e) edit,
> (mc) mine-conflict, (tc) theirs-conflict,
> (s) show all options: mc
> Conflict discovered in 'foo2'.
> Select: (p) postpone, (df) diff-full, (e) edit,
> (mc) mine-conflict, (tc) theirs-conflict,
> (s) show all options: mc
> G foo1
> G foo2
> Updated to revision 2.
>
> The summary is now at the END!

I don't think the per-file notifications should be grouped together at
the end. (They are a form of progress reporting.)

I agree that just a single "Updated to revision REV." line should be
printed at the end

> In subversion/svn/update-cmd.c a notify()-function is registered which
> gets called whenever there is new information that libsvn_client wants
> to pass through. My idea was to create another notify()-callback inside
> libsvn_client that could store the notifications the command produces
> and then at the end call the original notify() function in svn. That way
> all notifications would get printed last. Is this a working solution?
>
> I assume that there are notifications which needs to be sent at exactly
> the right time. How do I know which notifications that can be sent at
> the end?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377047
Received on 2009-07-30 18:59:48 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.