Summary of Subversion tree-conflicts meeting

The following are the folks that I recall being present at the Subversion
technical discussion which occurred at CollabNet HQ this past Thursday evening:

   Ben Collins-Sussman (via phone)
   Bhuvaneswaran
   Bob Jenkins (CollabNet)
   C. Michael Pilato
   Dan Rall
   David James (via phone)
   Hyrum Wright (via phone)
   Jack Repenning
   Kamesh Jayachandran
   Karl Fogel
   Mark Phippard
   Paul Burba
   Rainer Heinold (CollabNet)
   Steve Elsesmore (Subclipse, CollabNet)

I asked Bob to summarize the problem we were there to discuss. In a
nutshell, it's the old tree-conflicts problem rearing its head in various
scenarios. Update pulls down text modifications to a locally
scheduled-for-delete file. Update pulls down deletion of a locally modified
file. 'svn merge' trying to apply changes to a deleted file. Changes to
renamed files not following the file's new location. Stuff that like.

The ways in which the user experience today is suboptimal seem to fall into
three major categories:

  1. Not notifying the user when certain of these sticky scenarios
     happen, leaving them bewildered and frustrated when their working
     copies don't look the way they ought to look. We do print such
     notifications as "Skipped missing target", but only in certain
     cases.

  2. Not persisting the problem state until the user makes a clear
     decision on how to handle it. Like I said earlier, we sometimes
     print a warning notification. But those can get lost in a sea
     of output, and don't prevent the user from committing bogus
     stuff accidentally when they fail to catch one of those
     notifications.

  3. Not automatically correcting some of the problem states,
     especially those around renames. Users would really love to
     have the Subversion client apply their local mods to the
     new location of a renamed file automatically, as if the
     rename action was handled client-side like a real OS 'mv'
     command.

Those of us at the meeting agreed that the solutions for those problems,
then, can come in three waves:

  1. Get universal problem notification going on.

  2. Actually implement tree conflicts, and maintain the property (as
     with file conflicts) that you can't commit changes to a directory
     marked as conflicted.

  3. Make the server and client smarter about copies and moves.

Steps 1 and 2 seemed attainable and would satisfy (in our opinions) the
majority of our users' frustrations in these parts. Step 3, on the other
hand, was deemed "gravy" (and purty difficult gravy to hit). At any rate,
it was generally agreed that we didn't have to implement the so-called "true
renames" to get any of this stuff.

Mark Phippard suggested that it would be best to tackle 1 and 2 at the same
time. Why? Because if you go through the effort of adding notification for
all the scenarios, you'd likely have to change that notification when step 2
comes along because you'd want to now report, for example, that the tree was
in a state of conflict -- not just that something was skipped or made
unversioned.

We identified issue 2282 as the "main" issue here. (Though, you'll notice
that it has *six (6)* other issues blocked on it!) Alas, I drew the short
straw, so it falls to me to drum up support for this effort and a sane plan
of attack.

What feels natural to me is to simply extend our existing mechanism for
marking entries as conflicted to this new tree conflict case. IIRC,
directories currently only use the property-conflict-file entry slot --
maybe the working-conflict-file slot could be used for directories in some
fashion? We could plop a conflict file into the directory (even an empty
one, or one whose contents explain what a tree conflict is), name it in this
entries file slot, and *poof* the directory is now in a state of conflict.
As an added bonus, we didn't change the working copy format incompatibly,
and I think older clients would still even recognize the conflict (because
svn_wc_conflicted_p intentionally doesn't take node kind into account).

I'm only beginning to wrap my head around some of this stuff. I anticipate
much discomfort in coming days as I continue to do so. But I welcome
thoughts and ideas in this space, so if you've got any, please share 'em.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand