Stefan Sperling wrote:
> We now support 3 different types of conflicts in trunk (text, prop,
> tree). I have for been contemplating the idea of reporting how many
> conflicts of each type occured during an update or merge.
> Here is a patch that implements this idea.
>
> With the patch applied, the output looks like this:
>
> Conflict discovered in 'alpha'.
> Select: (p) postpone, (df) diff-full, (e) edit,
> (mc) mine-conflict, (tc) theirs-conflict,
> (s) show all options: p
> --- Merging r2 through r5 into '.':
> C alpha
> U epsilon/zeta
> U beta
> There was 1 text conflict.
Excellent!
> More complicated example:
>
[...]
> There was 1 text conflict and 2 tree conflicts.
> 2 paths were skipped.
OK. As a bikeshed, rather than trying to print each message in the most
natural-sounding English, I would write something more like:
Summary of conflicts:
1 text conflicts
2 tree conflicts
2 skipped paths
{
if (text_conflicts > 0)
printf(" %d text conflicts", text_conflicts);
etc.
}
Jens pointed out in his reply how we can generate proper natural
language translations for singular and plurals, but I would just use the
same text regardless of what the actual number is. This way also avoids
having to get "was")
> In case of multi-working-copy updates, stats are currently
> reported separatly for each working copy:
>
> Conflict discovered in 'trunk2/alpha'.
> Select: (p) postpone, (df) diff-full, (e) edit,
> (mc) mine-conflict, (tc) theirs-conflict,
> (s) show all options: p
> C trunk2/alpha
> U trunk2/epsilon/zeta
> U trunk2/beta
> Updated to revision 5.
> There was 1 text conflict.
> Conflict discovered in 'trunk3/alpha'.
> Select: (p) postpone, (df) diff-full, (e) edit,
> (mc) mine-conflict, (tc) theirs-conflict,
> (s) show all options: p
> C trunk3/alpha
> U trunk3/epsilon/zeta
> U trunk3/beta
> Updated to revision 5.
> There was 1 text conflict.
>
> I think this is OK, because reporting stats in one batch
> for all working copies at the very end would complicate
> the code a lot :-P
Yes, I think that is good enough for now.
> I'll do the same thing for 'svn status' if people agree with
> the general idea.
There is not quite the same issue with "svn status". The user can always
repeat the "status" command and view the results more carefully if the
information scrolled off the screen the first time. Also, the user's
next question is going to be "What files?", and the "status" command is
already the way to answer that.
With the existing "status" command, the user might try something like
* svn st | egrep "^(C|.C|......C)
(Is that the right number of dots? ;)
So, I think "svn status" should be able to
* print the items with an "important" status at the end of the list
or
* print only the items with an "important" status
And then I don't think it needs a summary at the end.
I've started on a modification to "svn status" to do the latter.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-17 17:19:46 CEST