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, but I *can* say that I believe they are the
likely worst offenders in this space.
I've taken the liberty of copying your ASCII-ized forms into our
notes/tree-conflicts directory (see r27454). Hopefully that will facilitate
refinement of the ideas contained therein.
Stefan Sperling wrote:
> Hello list,
>
> does anybody feel a twitch in their tummy when I say "tree conflicts"?
>
> If you don't know what I'm talking about, see here for the longest
> mailing list thread we could find on the issue:
> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=362008
>
> And see here for the corresponding issue #2282, "handle file
> delete/edit/add conflicts: tree changes and conflicts":
> http://subversion.tigris.org/issues/show_bug.cgi?id=2282
>
> The problem is still unsolved, and hinders adoption of Subversion in at
> least one corporate environment we know of. It especially presents a
> major hassle for people who do a lot of refactoring, but even if you
> don't do a lot of that you may run into the issue sooner or later.
>
> We have funding, good relations to CollabNet and are willing to throw
> developers at the problem. "We" is elego, a company based in Berlin,
> Germany. Some of you may have met us at SubConf 2007. See
> http://www.elego.de if you are interested in who we are and what we do.
>
> We'd like to propose the use cases below as a basis for further design
> discussion, with the goal of fixing the tree conflicts problem in time
> for Subversion 1.6.
>
> The use cases are based on a scenario paper "SVN move/rename problems &
> suggested improvements" submitted by a corporate Subversion user.
>
> The paper has been attached to issue 2282 by Michael Pilato, (see
> "Additional comments from C. Michael Pilato Tue Oct 23 07:15:06 -0700
> 2007"), and is in PowerPoint format. We have converted and adapted the
> diagrams in the original paper into ASCII for your convenience so you
> can easily view them in your mail reader. It really helps to be able to
> continuously refer to the diagrams while reading the use case
> descriptions. We've also rephrased the use case descriptions to try to
> make them as accessible as possible.
>
> As a first step, we concern ourselves with the first three of the six
> use cases described in the paper. We plan to handle the remaining three
> use cases later.
>
> We still recommend viewing the original paper if possible as an
> additional source of information. But note that in our description, we
> have modified the use cases in the paper so that developer A always
> commits first, and developer B always has to clean up the conflicts. In
> our opinion this makes it easier to think about the different use cases
> consistently and how they relate to one another.
>
> We have reproduced the behaviour described in each use case with the
> current trunk. (I personally think that writing recipes for these use
> cases is a great way to learn about them.) We also have cmdline test
> cases reflecting the current trunk behavior.
>
> We're open to any kind of questions, criticism and suggestions you may
> have. Feel free to reply inline inside the use case descriptions.
> Thanks for your time, it is appreciated :)
>
> Regards,
> Steve Butler <sbutler@elego.de>
> Stefan Sperling <stsp@elego.de>
>
>
> = Use Case Descriptions =
>
> == Use Case 1 ==
>
> During an update, a file modification is merged onto a file move.
>
> === Current behavior UC 1 ===
>
> Developer A modifies Foo.c and commits it to the repository.
>
> Developer B has simultaneously moved Foo.c to Bar.c in his working
> copy.
>
> B cannot commit because the working copy is out of date, so B runs 'svn
> update'. The update will apply A's modifications to Foo.c in the
> repository to Foo.c in B's working copy.
>
> === Problems with current behavior UC 1 ===
>
> First problem:
>
> A's modification of Foo.c will effectively be reverted by B's new
> revision. Foo.c will be deleted in the new revision, and Bar.c will be
> added with the content of the original Foo.c before A's modifications.
> Hence A will likely get angry with B.
>
> Second problem:
>
> B is not explicitly warned about reverting A's modification of Foo.c.
> The only visible warning is that Foo.c is left behind unversioned in
> B's working copy because it has "local" modifications (which were in
> fact made by A). This will likely escape B's attention.
>
> === Diagram of current behavior UC 1 ===
>
>
> (edit)
> wcA -- Foo.c' ------->
> / |
> / |commit
> repos / v
> -- Foo.c -------------- Foo.c' --------------- Bar.c --->
> \ | ^
> \ |update |commit
> \ v |
> wcB -- +Bar.c ---------- +Bar.c ---- Bar.c --->
> (move) -Foo.c -Foo.c' ?Foo.c' (unversioned)
>
>
> === Desired behavior UC 1 ===
>
> When user B updates, A's modifications to Foo.c should be merged into
> Bar.c. Signal a text conflict if necessary.
>
> Foo.c should be deleted from B's working copy.
>
> A tree conflict should be signalled to inform B of the new changes
> to Bar.c, so that B can review the modified Bar.c before committing it.
>
> === Diagram of desired behaviour UC 1 ===
>
>
> (edit)
> wcA -- Foo.c' ------->
> / |
> / |commit
> repos / v
> -- Foo.c --------------- Foo.c' ------------------------ Bar.c' --->
> \ | ^ ^
> \ |update |commit |commit
> \ v |(fails) |
> wcB -- +Bar.c ------------ +Bar.c' -------------->
> (move) -Foo.c -Foo.c ^
> |
> resolved
>
>
> == Use Case 2 ==
>
> During an update, a file move is merged onto a file modification.
>
> This is essentially the same as Use Case 1, with the difference that
> this time, B does the edit and A does the move.
>
> === Current behavior UC 2 ===
>
> Developer B modifies Foo.c in his working copy.
>
> Developer A has simultaneously moved Foo.c to Bar.c and commits
> the move to the repository.
>
> B cannot commit because his working copy is out of date, so B runs
> 'svn update'. The next update will add Bar.c (with the same content
> as the original Foo.c) to B's working copy, and delete Foo.c from
> B's working copy. Since B made local modifications to Foo.c,
> it will not be deleted from disk but left behind unversioned.
>
> === Problems with current behavior UC 2 ===
>
> Developer B may not notice that Foo.c fell out of version control.
> B's source tree in the working copy likely builds fine because
> Foo.c is still present on disk.
> So B may commit an incomplete change set, possibly breaking the tree.
> Everybody will get angry with B if this happens.
>
> === Diagram of current behaviour UC 2 ===
>
>
> (move)
> wcA -- +Bar.c ------->
> / -Foo.c |
> / |commit
> repos / v
> -- Foo.c --------------- Bar.c ----------------------->
> \ | ^
> \ |update |commit
> \ v |(no-op)
> wcB -- Foo.c' ------------ Bar.c ------->
> (edit) ?Foo.c' (unversioned)
>
>
> === Desired behavior UC 2 ===
>
> In B's working copy, the update should add Bar.c and merge the local
> modifications to Foo.c into Bar.c. Signal a text conflict if necessary.
>
> Foo.c should be deleted from B's working copy.
>
> A tree conflict should be signaled to inform B that Foo.c has been
> renamed to Bar.c
>
> === Diagram of desired behaviour UC 2 ===
>
>
> (move)
> wcA -- +Bar.c ------->
> / -Foo.c |
> / |commit
> repos / v
> -- Foo.c --------------- Bar.c -------------------------- Bar.c'--->
> \ | ^ ^
> \ |update |commit |commit
> \ v |(fails) |
> wcB -- Foo.c' ------------+Bar.c' ------------------------>
> (edit) -Foo.c ^
> |
> resolved
>
> == Use Case 3 ==
>
> During an update, a file move is merged onto a conflicting file move.
>
> === Current behavior UC 3 ===
>
> Developer A moves Foo.c to Bar.c and commits the move to the repository.
>
> Developer B has moved Foo.c to Bix.c in his working copy.
>
> B cannot commit because his working copy is out of date, so B runs
> 'svn update'. The update will add Bar.c to B's working copy and
> delete Foo.c from B's working copy (the latter is a no-op).
>
> === Problems with current behavior UC 3 ===
>
> After B's next commit, the content of the original Foo.c
> will exist twice in the source tree under two different paths,
> namely Bar.c and Bix.c, respectively.
>
> This may not have been intended.
>
> === Diagram of current behavior UC 3 ===
>
>
> (move)
> wcA -- +Bar.c ------>
> / -Foo.c |
> / |commit
> archive / v
> -- Foo.c --------------- Bar.c ------------------ Bar.c --->
> \ | ^ Bix.c
> \ |update |commit
> \ v |
> wcB -- +Bix.c ---------- +Bix.c ------->
> (move) -Foo.c Bar.c
>
>
> === Desired behavior UC 3 ===
>
> A tree conflict should be signaled to inform B of the conflicting rename
> operation. B can now decide on deleting either file or committing both.
>
> === Diagram of desired behavior UC 3 ===
>
>
> (move)
> wcA -- +Bar.c ------>
> / -Foo.c |
> / |commit
> archive / v
> -- Foo.c --------------- Bar.c -------------------------- Bar.c -->
> \ | ^ ^ (or Bix.c,
> \ |update |commit |commit or both)
> \ v |(fails) |
> wcB -- +Bix.c ---------- +Bix.c -------------->
> (move) -Foo.c Bar.c ^
> |
> resolved
>
>
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Oct 29 14:03:35 2007