Re: tree conflict use cases

On Mon, Oct 29, 2007 at 09:03:04AM -0400, C. Michael Pilato wrote:
> Stefan, thanks for converting those use-cases into ASCII forms. I can't say
> with 100% confidence that they represent the total sum of tree conflicts
> use-cases in the universe,

Of course they don't.

The space of tree conflict problems is theoretically infinite.
Directory trees can have arbitrary depth and have no order
imposed on them.

> but I *can* say that I believe they are the
> likely worst offenders in this space.

I don't know about that. The use cases don't even touch crazy but
entirely possible situations like update pulling down a file on
top of a directory with the same name.

Or for example, imagine trying to *automatically* merge two trees
with an arbitrary common ancestor into a meaningful tree,
but with one having changed into an ordered binary tree (a directory
tree with each directory having exactly two subdirectories) and the
other one having changed into a list (a directory tree with each
directory only having a single subdirectory).
This is a theoretical scenario, but it shows that the use cases
merely touch the surface of the problem space.

But Subversion's behaviour in these particular use cases hinders
its adoption in at least one corporate environment. And the use
cases are well defined. And I think that the desired behaviour
can be implemented without changing the current behaviour to
a great extent.

Also, other SCMs reportedly handle these particular use cases
much better than Subversion currently does. I've been told that
some of the desired behaviour described in the use cases
practically makes Subversion behave a bit more like ClearCase.

All this is why we are working on these particular 6 use cases,
the first three of which this thread is about.
There may be many, many other use cases worth considering,
but they are outside the scope of our current goals.

</rant>

Reading through the README in the libsvn_wc directory this morning,
I noticed that it mentions tree conflicts.

I have some questions and remarks.

Quote:

  Therefore, while Subversion does everything it can to fold conflicts
  intelligently (doing at least as well as CVS does), in extreme cases
  it is acceptable for the Subversion client to punt, saying in effect
  "Your working copy is too out of whack; please move it aside, check
  out a fresh one, redo your changes in the fresh copy, and commit from
  that."

For the use cases described it does not even punt, it just behaves
misleadingly. So the current behaviour seems to conflict with the
working copy library design goals.

  Usually it offers more detail than that, too. In addition to the
  overall out-of-whackness message, it can say "Directory foo was
  renamed to bar, conflicting with your new file bar; file blah was
  deleted, conflicting with your local change to file blah, ..." and so
  on. The important thing is that these are informational only -- they
  tell the user what's wrong, but they don't try to fix it
  automatically.
  
Interesting, I've never seen svn explain conflicts to me this way.
But this is very interesting because we need exactly that to
report tree conflicts to the user in a comprehensible way.

Is this an idea that has been sitting in the README all this
time or is there actually code somewhere that implements this?
I will search libsvn_wc later today, but I thought I might ask
about it here as well because in case this hasn't been implemented
it would interesting to know why.

Another interesting bit is:

  All this is purely a matter of *client-side* intelligence. Nothing in
  the repository logic or protocol affects the client's ability to fold
  conflicts. So as we get smarter, and/or as there is demand for more
  informative conflicting updates, the client's behavior can improve and
  punting can become a rare event. We should start out with a _simple_
  conflict-folding algorithm initially, though.

So I guess by now, it's time to get smarter, at least with
respect to the use cases described in the paper.

(Also, I guess we will need to partially track renames on the
server side as well for some use cases, but more on that later.
I don't really want to talk about design ideas before that community
has accepted the use cases. So far there hasn't been much feedback...)

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