Quoting Julian Foad <julianfoad_at_btopenworld.com>:
> On Mon, 2008-10-20 at 19:01 +0100, Stefan Sperling wrote:
>> On Mon, Oct 20, 2008 at 03:46:29PM +0100, Julian Foad wrote:
>> > The UI is up for comment - both the command line to invoke it, and the
>> > output.
>> > [[[
>> > $ svn st
>> > C A/D/G
>> > ? C A/D/G/rho
>> > D C A/D/G/pi
>> > $ svn st --conflicts)
>> > ? C (D>M) A/D/G/rho
>> > D C (M>D) A/D/G/pi
>> > ]]]
>> > Here, "(D>M)" means "an incoming Delete onto an existing Modified node".
>> I'd prefer (D->M), since this provides a more recognisable image
>> of an arrow (which I think your > is supposed to allude to).
> Heh. Sure. Yes, that's what it means.
> I was wondering if we could include revision numbers of the changes:
> (D r34567 -> M r34567)
I'm not sure what we'd print for local mods, then. Maybe revnums are too
> (I'd have to think about whether we're printing old/new/theirs/mine or
> what exactly)
> and/or whether we could include text-mod and prop-mod indicators in each
> (D_ -> _M) foo # meaning: delete conflicted with prop-mod
> to be more precise. Especially as the non-tree conflict indication could
> then be similar:
> (MM -> _M) foo # meaning: text applied ok, prop mod conflicted
> Or something like that.
If the --conflicts format is an extension of the existing formats, then
the first 7 columns already describe any local mods, including conflict
Here's a stab at printing both local mods and the extra conflict columns.
$ svn status --conflicts
! C (MM->! ) bar
D C ( M->D ) baz
M C (D -> M) bip
Property conflicts: 1
Tree conflicts: 3
I suggest we need the new notation for tree conflicts only. Perhaps
only for the incoming changes, because the text after the arrow seems
to duplicate the first two columns anyway. Or at least, it will as
soon as we manage to skip tree conflict victims. The status is a bit
simpler without the arrow:
$ svn status
! C (MM) bar
D C ( M) baz
M C (D ) bip
Property conflicts: 1
Tree conflicts: 3
For more information on a tree conflict, run 'svn info <path>'.
$ svn info bar
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.
> We aren't perhaps storing enough details of the tree conflict at the
> moment to be that precise.
True. We store only one field for the incoming action (deleted, modified,
etc). I suppose one more field for the incoming property action would be
>> I like the idea of parentheses, since it visually groups the details
>> about tree conflicts, and makes them stand. If they were just letters
>> in yet another column, it would not be as easy to parse.
>> > In this patch, this indication is coded on the assumption that it's a
>> > tree conflict, but I feel the command ought to show all kinds of problem
>> > mentioned above.
> I don't want to spend much time thinking about how to represent non-tree
> conflicts right now, but I'll make that the eventual aim.
>> > Note also that a briefer summary of such problems has just been
>> > implemented as a message at the end of an update/switch/merge command.
>> > This ought to be complementary to that.
>> Maybe the summary should also print a last line saying something like
>> "Run 'svn status --conflicts' for more information", once the UI is set
>> in stone.
> - Julian
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
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 16:24:49 CEST