Stephen Butler wrote:
> 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 think that's overkill, choking the reader with surplus information.
But is there even a way of retrieving revision information? Wouldn't that be
something to write in `svn info'?
>
> I'm not sure what we'd print for local mods, then. Maybe revnums are too
> much information.
>
>>
>> (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
>> position:
>>
>> (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
> types.
>
> Here's a stab at printing both local mods and the extra conflict columns.
>
> $ svn status --conflicts
> MC foo
> ! C (MM->! ) bar
> D C ( M->D ) baz
> M C (D -> M) bip
> Conflict summary:
> 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
Yeah!
> soon as we manage to skip tree conflict victims. The status is a bit
> simpler without the arrow:
>
> $ svn status
> MC foo
> ! C (MM) bar
> D C ( M) baz
> M C (D ) bip
> Conflict summary:
> Property conflicts: 1
> Tree conflicts: 3
> For more information on a tree conflict, run 'svn info <path>'.
>
> $ svn info bar
> ...
I really like this one! For the well informed, this could also compress to
$ svn status
MC foo
! MM bar
D M baz
M D bip
...
but I guess it doesn't look like a conflict anymore. Maybe we can at least
remove the space between the C and the brackets:
$ svn status
MC foo
! C(MM) bar
D C( M) baz
M C(D ) bip
...
And I'd even go as far as
$ svn status
MC foo
! CMM bar
D C M baz
M CD bip
...
, fighting for every column. Yes, I think this last one is my favourite.
It's a nice compromise between brevity and visibility.
> 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
>
>>
>> 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
> straightforward.
+1 as well.
--
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2008-10-21 16:51:54 CEST