Summary of Subversion tree-conflicts meeting

["C. Michael Pilato" <cm...@collab.net>]

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 <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: Summary of Subversion tree-conflicts meeting

[Mark Phippard <ma...@gmail.com>]

Would it help to take specific scenarios and map out the sort of
change that we might want to do?  It seems like it could help
determine the scope of the effort.  The one concern I had after our
meeting was that we focused a lot on the moment the problem occurs,
and what we could do to identify it, and not a lot on how this will
effect the workflow after the problem occurs.

Let me take one of the simpler scenarios and illustrate what I mean.
I think we might want to do this for more scenarios later.

Scenario:  User has made local modifications to a file.  Another user
has committed a rename of the file in the repository.

What happens today:  User runs update.  The new file name is added to
their working copy.  Subversion wants to delete the old file name, but
since there are local modifications it instead just makes the file
unversioned.  It is reported as a 'D'elete and 'A'dd in the console
output.

What should ideally happen: Subversion should move the local file to
the new name, and then update based on the repository file.  The old
file would be deleted and the new named file would likely appear
modified when svn st is run.

What should "next best" happen:  The 'D'elete file should be marked as
a 'C'onflict or some new designation.  The original pristine version
of the file should be maintained so that the user can run svn diff to
create a patch and apply it to the moved file.

svn revert would remove the conflict and the pristine version, and
possibly delete the local file too.
svn add should remove the conflct, mark the file as scheduled add, and
replace the pristine copy.
svn resolved should probably report an error that it cannot do
anything.  Maybe indicate that svn add or revert should be run.

svn commit would fail until the conflict is removed.

Not sure what should happen if svn update/switch/merge are run and
they want to do something with a file in this new state.

This is complicated.  Hopefully once we work through a couple of these
scenarios it will always just be the same solution replaying over and
over.



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org