Progress on update-move [was: 1.8 Progress]

[Julian Foad <ju...@btopenworld.com>]

Philip Martin wrote:

> Some remaining tasks:
> 
>    - delete should remove working items
> 
>    - notifications
> 
>    - switch instead of update

r1434352 teaches it to record a 'switch' as such.

- Julian

>    - finite depth update conflict
> 
>    - tests (may need notifications)
> 
> I plan to work on delete next.

Re: Progress on update-move [was: 1.8 Progress]

[Stefan Sperling <st...@elego.de>]

On Thu, Jan 17, 2013 at 02:55:50PM +0100, Stefan Sperling wrote:
> What would also help is some UI design that specifies which kinds of
> tree conflicts we expect 1.8 to resolve automatically during 'svn
> resolve', and how such cases are resolved depending on what options
> the user is choosing.

Actually, UI design is only part of this. Another part is behavioural
specification for several tree conflict resolution cases. The UI design
should follow from there.

Re: Progress on update-move [was: 1.8 Progress]

[Stefan Sperling <st...@elego.de>]

On Wed, Jan 16, 2013 at 07:50:57PM +0000, Julian Foad wrote:
> Philip Martin wrote:
> 
> > Some remaining tasks:
> > 
> >    - delete should remove working items
> > 
> >    - notifications
> > 
> >    - switch instead of update
> 
> r1434352 teaches it to record a 'switch' as such.
> 
> - Julian
> 
> >    - finite depth update conflict
> > 
> >    - tests (may need notifications)
> > 
> > I plan to work on delete next.

What would also help is some UI design that specifies which kinds of
tree conflicts we expect 1.8 to resolve automatically during 'svn
resolve', and how such cases are resolved depending on what options
the user is choosing.

Currently, --accept=mine-conflict (and the corresponding 'mine-conflict'
answer at the interactive conflict prompt) maps to updating a locally
moved away file or directory after a tree conflict, which is flagged on
the moved-away directory after an update/switch. This is what Philip is
talking about above.

We should also implement --accept=theirs-conflict for this case, and
define the desired behaviour (I've added two tests for this, see
r1434665 and r1434668).

Do we want to keep using mine-conflict and theirs-conflict like this?
Is this a good UI, or should we rename these options?

Should offer similar options for additional tree conflict cases in 1.8,
or do we defer that to 1.9? If we defer, are we expecting the options we
put into the UI for 1.8 to still work in the exact same way in 1.9?

Ideally, we should have a decent idea about the UI we're aiming for
once we have implemented 'interactive tree conflict resolution' in
the best possible way for as many tree conflict cases as possible.

I'm not that good at UI design so I am looking for some help :)