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

Re: svn commit: r34329 - in branches/tc_url_rev/subversion: include libsvn_wc svn

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 23 Nov 2008 12:16:24 +0000

On Sun, Nov 23, 2008 at 02:58:06AM +0100, Neels J Hofmeyr wrote:
> Stefan Sperling wrote:
> > On Fri, Nov 21, 2008 at 07:37:54PM -0800, neels_at_tigris.org wrote:
> >> Author: neels
> >> Date: Fri Nov 21 19:37:54 2008
> >> New Revision: 34329
> >>
> >> +const char *
> >> +svn_wc_operation_str(svn_wc_operation_t operation, apr_pool_t *pool)
> >> +{
> >> + switch(operation){
> >> + case svn_wc_operation_update:
> >> + return SVN_WC__OPERATION_UPDATE;
> >> + case svn_wc_operation_switch:
> >> + return SVN_WC__OPERATION_SWITCH;
> >> + case svn_wc_operation_merge:
> >> + return SVN_WC__OPERATION_MERGE;
> >
> > You haven't marked the above strings for translation.
>
> Say, do the svn commands "update", "switch", etc. get *translated*??

oops :)

Well, I suppose not, sorry.

> ...
> >> svn_cmdline_printf(pool,
> >> _("Tree conflict: %s\n"
> >> - " incoming version: %s\n"
> >> - " local version: %s"),
> >> - desc, incoming_version, local_version);
> >> + " Older version: %s\n"
> >> + " Their version: %s"),
> >> + desc, older_version, their_version);
> >
> > I'm wondering why we use "older" and "their" for merge.
> > It only makes sense for update.
> >
> > In case of merge, wouldn't it be more straightforward to say
> > "merge-right" and "merge-left"?
>
> True. I was thinking something like that but it wasn't as clear as you said
> it. Thanks.

Great.

> >> @@ -35,13 +35,13 @@ select_action(const svn_wc_conflict_desc
> >> case svn_wc_conflict_action_add:
> >> return _("add");
> >> case svn_wc_conflict_action_delete:
> >> - return _("delete");
> >> + return _("delete or move");
> >
> > I don't think this is a good idea.
> >
> > Part of what I did not like about the old long human readable
> > descriptions was that they went out of their way to explain
> > to users that a move may be involved.
> >
> > I am now thinking we should not pretend to be smarter than we
> > really are. Let's just say "delete", because we really don't
> > know any better. And people *know* that Subversion represents
> > moves as delete+add. We don't hide this fact in the update/status
> > output either. Just saying "delete" is more consistent.
> > Mercurial also does the same, btw., it just says delete.
> >
> > Once the working copy has been made aware of moves, we can
> > adjust the output without having to lie about what we know.
>
> I was thinking of users that don't know much about nothing. "What? I didn't
> *remove* that file, did I???"
>
> Then again, I don't mind it all that much. I'll revert that.

OK.

> > - *desc = apr_psprintf(pool, _("incoming %s, local %s"), action, reason);
> > + *desc = apr_psprintf(pool, _("local %s, incoming %s (upon %s)."),
> > + reason, action, operation);
> > I liked it better without parentheses and full-stop, and I don't think
>
> I like it better *with*. But whatever. I'll change it but quit bikeshedding. :)
>
> > that printing the operation which produced the conflict really makes
> > much sense.
>
> I think it does. It tells people what they were trying to do, and what they
> need to do to fix it. If we merge into an update-conflicted working copy,
> and that merge creates more tree-conflicts... let's just leave it there.

OK, let's leave it in, but can we change the output to this?

 + *desc = apr_psprintf(pool, _("local %s, incoming %s by %s"),
 + reason, action, operation);

This makes the operation visible but does not clutter the output
with parens, so nothing suggests that any one piece of information
in that line is more important than any other.

Anyway, we're making up the output based on gut-feeling, not human
interface research guidelines. So there's not much point in arguing.
Let's just try to find a form of output we're all more or less
happy with.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-23 13:16:42 CET

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.