On Wed, 12 Sep 2007, Mark Phippard wrote:
> On 9/12/07, Daniel Rall <email@example.com> wrote:
> > On Sep 12, 2007, at 8:23 AM, Mark Phippard wrote:
> > > Dan,
> > >
> > > Starting to test this feature to implement in the merge client. Is
> > > this what you expected the command line output to look like? It seems
> > > like the line breaks are not right:
> > >
> > > $ svn merge -g
> > > --- Merging r5 through r8:
> > > U src/com/collabnet/banking/tests/BankingTests.java
> > > Conflict discovered in 'src/com/collabnet/banking/models/
> > > BankAccount.java'.
> > > Select: (p)ostpone, (d)iff, (e)dit, (h)elp : p
> > > C src/com/collabnet/banking/models/BankAccount.java
> > > U docs/products/index.html
> > > U docs/about/index.html
> > > subversion/libsvn_client/merge.c:2184: (apr_err=155015)
> > > svn: One or more conflicts were produced while merging r4:8 into
> > > '.' --
> > > resolve all conflicts and rerun the merge to apply the remaining
> > > unmerged revisions
> > > $
> > I was assuming that target_wcpath (the input to the
> > make_merge_conflict_error routine which produces the error which
> > causes this output) could potentially be quite long. Given that, how
> > do you suggest the line breaks on this output should go (e.g. move
> > some of "resolve all ..." up onto the previous line)?
> When I ran it from Subclipse, I noticed this -- since the target
> became an absolute path. It looked better for sure.
Okay, good. I was concerned that it might not be a common enough case
to justify printing '.' a lot of the time, and adding an extra a line
to the error message text.
> What about the next two lines? They seem like they are breaking
> early. Is there a standard for this or is to allow translation room?
We typically break our message text before 80 characters, just as we
break our source code, on the grounds that it might be displayed in a
terminal window (or small viewer window in an IDE).
If I add one more word to line 3 of the text, it'll look like this:
svn: One or more conflicts were produced while merging r4:8 into
resolve all conflicts and rerun the merge to apply the remaining unmerged
Since I already have a fourth line, I figured I'd go for a more
consistent length, which also resulted in slightly more comprehensible
source code for the code which generates the error message.
> Maybe the message could just omit the path? That information is
> readily available in the previous messages.
That assumes a trivial merge. In a more significant merge -- which I
assume to be the more common case -- with the command-line client, the
notification will likely have long-since scrolled off the screen.
Received on Fri Sep 14 19:47:40 2007
- application/pgp-signature attachment: stored