Re: Tree Conflicts and User Interface

Julian Foad wrote:
> A node is either tree-conflicted (as a victim), or can have (text and/or
> prop) conflicts: one of:
>
> - not in conflict
> - tree conflict victim
> - prop conflicts
> - text conflict
> - text and prop conflicts

I'd like to draw attention to D, M: files and directories, when victims of
tree-conflicts, are mostly scheduled for deletion or locally modified. That
is valuable information!

working copy 1: working copy 2: `svn update' in wc 2:
M alpha D alpha D V alpha
D beta M beta M V beta
(committed) (locally) ...or something.

Looking around, I realized this:

$ svn --version
svn, version 1.5.1 (r32289)
   compiled Sep 4 2008, 18:42:55
[...]

$ svn help status
[...]
  The first six columns in the output are each one character wide:
    First column: Says if item was added, deleted, or otherwise changed
      ' ' no modifications
      'A' Added
      'C' Conflicted
      'D' Deleted
      'I' Ignored
      'M' Modified
      'R' Replaced
      'X' item is unversioned, but is used by an externals definition
      '?' item is not under version control
      '!' item is missing (removed by non-svn command) or incomplete
      '~' versioned item obstructed by some item of a different kind
    Second column: Modifications of a file's or directory's properties
      ' ' no modifications
      'C' Conflicted
      'M' Modified
    Third column: Whether the working copy directory is locked
      ' ' not locked
      'L' locked
    Fourth column: Scheduled commit will contain addition-with-history
      ' ' no history scheduled with commit
      '+' history scheduled with commit
    Fifth column: Whether the item is switched relative to its parent
      ' ' normal
      'S' switched
    Sixth column: Repository lock token
      (without -u)
      ' ' no lock token
      'K' lock token present
      (with -u)
      ' ' not locked in repository, no lock token
      'K' locked in repository, lock toKen present
      'O' locked in repository, lock token in some Other working copy
      'T' locked in repository, lock token present but sTolen
      'B' not locked in repository, lock token present but Broken
[...]

So, there already *IS* a multitude of columns? So what's the big deal with
adding another column for tree-conflicts -- isn't that the obvious choice?

Even update has a third column:

$ svn help update
[...]
  A 'B' in the third column signifies that the lock for the file has
  been broken or stolen.
[...]

So why not report tree-conflicts in an added column *only* when
tree-conflicts are to be reported? I know that stsp wouldn't like it to look
like this:

$ svn up
A alpha
G beta
D V gamma
D delta

$ svn status
M beta
D epsilon
M V gamma
M zeta

But I myself wouldn't mind it at all: I think it's even an added bonus,
because it visually sets tree-conflicted items apart from "normal" ones.

In a "third" column, couldn't we also actually use a 'T', because it's an
all new column? (Have these things been considered in another thread??)

~Neels

-- 
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