About omitting the "local" status letters because they're already
printed in the first two columns:
In an update/switch, that's true. In a merge, that's not true: the local
change was probably committed on the branch so does not show up in the
first two columns.
I think we need the full "(incoming -> local)" because of merge
situations, even if it's a semi-redundant in up/sw situations.
About printing two letters (text and prop) for each side, like "(_M ->
D_)", that's more detail than necessary. If we say a tree conflict
exists because an item was modified in some way, that's enough
information for a first pass.
So I'm still advocating the style I proposed at first - something like
"__C (M->D) foo.c".
Remember that this proposal is for a way to show what's most useful as a
summary of conflicts, not for a way to shoe-horn the info into the
existing "status" output or any existing command. If it ends up fitting
into an existing command's output, that's great.
Stefan Sperling wrote:
> On Tue, Oct 21, 2008 at 04:51:14PM +0200, Neels J. Hofmeyr wrote:
> > Stephen Butler wrote:
> > > Here the extra --conflicts info is simply the incoming changes (content
> > > and props). In fact, it's short enough that we could avoid the proposed
> > > --conflicts flag and simply print the extra columns by default.
> >
> > +1
That works if the extra columns are few - like just one or two more
status letters immediately after the "C" that indicates a tree conflict.
I was expecting to provide a moderate amount of info, probably more than
that, eventually. But (see below) maybe not.
> I don't see how not printing conflict information by default would
> be useful at all...
We're always going to print (at least) the basic "C" for a tree conflict
in the plain "svn status" output. So the question is whether we are
going to want more details, and if so whether they should still be
printed in all normal "svn status" displays. (Perhaps only with "-v".)
> Wasn't --conflicts meant to act as a filter in Julian's original
> proposal? I.e. 'svn status' would print the information by default
> anyway, but with --conflicts, it would display *only* conflicts?
Yes.
> In the case of many conflicts in a large source tree, that would
> be useful.
As well as filtering to output ONLY items in conflict, I was thinking
that it would ALSO extend the amount of info printed per item. But
actually I don't like a single option to act in two orthogonal ways like
this. (The current "-v" does something similar, and I almost never want
both of its effects.)
BUT ...
$ svn st | grep "^......C"
is already a workable solution (with "svn info" for more detail), so
this new UI is not essential. I really have to concentrate on the other
things that are essential. Unless anyone else is doing this UI right
now, we can come back to this afterwards.
- 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-21 19:25:39 CEST