[tree conflicts] Dropping user-visible files from the design (was: Re: question about the update editor (essentially))

On Wed, Dec 12, 2007 at 10:03:52PM +0100, Stefan Sperling wrote:
> Dear working copy gods and other svn-hacking fellows,
>
> To create a user-visible tree conflicts report file,
> I call a function called "svn_wc__write_tree_conflict_report()".

I had a nice discussion with David Glasser on IRC about this yesterday.

Somewhere in the middle of trying to explain the issue to
David, I took a step back again and thought about why we are
actually trying to create this file.

The answer I found somewhere in the very back of my head was that
as far as I recall the idea of the user-visible file was proposed
at a time where API changes were to be avoided.

Given that we are now changing existing API *and* the working copy
format anyway, what about changing the design a little, more particularly
the way tree conflict information is presented to the user?

I propose the following:

When an update that caused tree conflicts has completed,
tree conflict information is stored in the entries file.
(This is no change of plan).

Now, instead of having a text file that mirrors that state of the data
in the entries file lying around in the working copy, we could have either
a separate svn command (unlikely) or an option to an existing svn command
such as "svn status" or "svn info" display the human readable tree conflict
description to the user. Any suggestions about what colour the exact command
should be?

We could also add an libsvn_wc API to query the working copy about
tree conflict data, so 3rd party tools like tortoiseSVN could easily
implement their own tree conflict information display, instead of
having to redirect the user to a text file.

"svn resolved <tree-conflict victim path>" would clear data about
the tree conflict victim from the entries file, instead of removing
the user visible file.

Oh, and if the temporary file really is desirable, we can still
re-add it to the design later. But keeping it in sync with the
entries file may turn out to be a bit of a burden in the long run...

Does this change sound reasonable?

-- 
Stefan Sperling <stsp@elego.de>                 Software Developer
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                 Geschaeftsfuehrer: Olaf Wagner