[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r28767 - in branches/tree-conflicts/subversion: include libsvn_client libsvn_wc svn svn/schema

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 8 Jan 2008 15:35:15 +0100

On Sun, Jan 06, 2008 at 11:10:43PM -0500, David Glasser wrote:
> I think moving this to 'svn info', and not requiring an extra flag, is
> the right idea.
>
> However, I think a lot of scripts, for better or for worse, try to do
> some parsing of svn info non-XML output. Even though it's not
> actually an officially supported format, it would be nice to keep the
> "key: value" syntax to some degree.

Yes I was thinking about that, too.

> Perhaps indent the tree conflict
> lines so they can't be confused with other fields?

It depends a bit on how we expect tools to parse the output.

> And can a single tree conflict desc be multiple lines, or is it just
> that there can be more than one? If the latter, maybe just have a bunch
> of "Tree conflict: " lines?

Well, there are a few choices.

At the moment, we have this:

  Last Changed Author: jrandom
  Last Changed Rev: 2
  Last Changed Date: 2008-01-08 15:16:10 +0100 (Tue, 08 Jan 2008)
  Tree conflicts:
  The update wants to delete the file 'rho'
  (possibly as part of a rename operation).
  You have edited 'rho' locally.
  
  The update wants to delete the file 'tau'
  (possibly as part of a rename operation).
  You have deleted 'tau' locally.
  Maybe you renamed it?
  
  The update wants to edit the file 'pi'.
  You have deleted 'pi' locally.
  Maybe you renamed it?

So the key is "Tree conflicts", and the current value
contains newlines and is totally geared towards human consumption.

The following would also be friendly to humans but still a tad unfriendly to
scripts, at least to those that parse svn info output
line by line and expect each line to be a key:value pair.

  Last Changed Author: jrandom
  Last Changed Rev: 2
  Last Changed Date: 2008-01-08 15:16:10 +0100 (Tue, 08 Jan 2008)
  Tree conflicts:
      The update wants to delete the file 'rho'
      (possibly as part of a rename operation).
      You have edited 'rho' locally.
      
      The update wants to delete the file 'tau'
      (possibly as part of a rename operation).
      You have deleted 'tau' locally.
      Maybe you renamed it?
      
      The update wants to edit the file 'pi'.
      You have deleted 'pi' locally.
      Maybe you renamed it?
 
The following would also be possible. It's very friendly to
scripts, but a hard to parse for humans:

  Last Changed Author: jrandom
  Last Changed Rev: 2
  Last Changed Date: 2008-01-08 15:16:10 +0100 (Tue, 08 Jan 2008)
  Tree conflict: The update wants to delete the file 'rho' (possibly as part of a rename operation). You have edited 'rho' locally.
  Tree conflict: The update wants to delete the file 'tau' (possibly as part of a rename operation). You have deleted 'tau' locally. Maybe you renamed it?
  Tree conflict: The update wants to edit the file 'pi'. You have deleted 'pi' locally. Maybe you renamed it?

I myself would tend to cater to the human user rather than scripts.
Because scripts can be fixed to deal with the new output, and it's done
once and forgotten about. Whereas humans do have to deal with UI
inconveniences every single time they come across them.

> (And is "tree conflict" going to be the official UI-level name for
> this? I guess so.)

Why not?

-- 
Stefan Sperling <stsp_at_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

  • application/pgp-signature attachment: stored
Received on 2008-01-08 16:04:57 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.