work-in-progress tree conflicts diff, please comment

C. Michael Pilato cmpilato at red-bean.com
Tue Jan 6 03:55:09 CST 2009


Stefan Sperling wrote:
> On Mon, Jan 05, 2009 at 09:47:57PM +0100, Stefan Sperling wrote:
>> Hi,
>>
>> the diff below adds an introduction to tree conflicts
>> to the end of the 'svn.tour' chapter.
> 
> Updated diff.
> 
> Contains some simplifications suggested by Neels Hofmeyr.
> Many thanks!

Review comments inline.

> Question:
> 
> The following steps I've lined out:
> 
>       <listitem><para>Check the file to be renamed for local
>           modifications.</para></listitem>
> 
>       <listitem><para>Delete the file at its old location, and
>           if it had local modifications, keep an on-disk copy
>           of the file at the old location. This on-disk copy
>           now appears as an unversioned file in the working
>           copy.</para></listitem>
> 
>       <listitem><para>Add the file, as it exists in the repository,
>           at its new location.</para></listitem>
>       </itemizedlist>
> 
> They do not take the copy improvements made for 1.5, by sussman, into account.
> http://subversion.tigris.org/svn_1.5_releasenotes.html#copy-move-improvements
> 
> However, it seems that this behaviour does still exists.
> When I run the attached shell script with 1.5.5, I get the described
> situation in the working copy.
> But weren't sussman's changes supposed to address this problem?

IIUC, sussman's changes were such that they *might* make a difference, if
the stars aligned correctly and the cactus plants in Nevada cast shadows
that were exactly 137% longer than the plants themselves and the repository
happened to send the tree changes in just the right order.  (I'm not a big
of fan of effectively-from-the-user-perspective non-deterministic behavior,
but I think that's what we've got today.  *shrug*)

> Index: src/en/book/ch02-basic-usage.xml
> ===================================================================
> --- src/en/book/ch02-basic-usage.xml	(revision 3397)
> +++ src/en/book/ch02-basic-usage.xml	(working copy)
> @@ -2284,6 +2284,71 @@
>    <!-- ================================================================= -->
>    <!-- ================================================================= -->
>    <!-- ================================================================= -->
> +  <sect1 id="svn.tour.treeconflicts">
> +    <title>Dealing with structural conflicts</title>

sect1 titles should be title-cased:  Dealing with Structural Conflicts

> +      
> +      <para>So far, we have only talked about conflicts at the level
> +        of file content. When you and your collaborators make overlapping
> +        changes within the same file, Subversion forces you to merge those
> +        changes before you can commit.</para>
> +        
> +      <para>But what happens if your collaborators move or delete a file
> +        that you are still working on? Maybe there was a miscommunication,
> +        and one person thinks the file should be deleted, while another
> +        person still wants to commit changes to the file. Or maybe your
> +        collaborators did some refactoring, renaming files and moving
> +        around directories in the process. If you were still working on
> +        these files, those modifications may need to be applied to the
> +        file at its new location.</para>
> +
> +      <para>Such conflicts manifest themselves at the level of directory
> +        tree structure, rather than file content. Conflicts at the level
> +        of file content are known as <quote>text conflicts</quote>,
> +        whereas conflicts at the level of directory tree structure are
> +        known as <quote>tree conflicts</quote>.</para>

Combine the "But what..." and "Such conflicts..." paragraphs, but lose the
late definition of "text conflicts" (which, by the way, we refer to
elsewhere as "textual conflicts").  I'd suggest just appending the following
to the "But what..." paragraph:

   Such conflicts manifest themselves at the directory tree structure
   level rather than at the file content level, and are known as
   <firstterm>tree conflicts</firstterm>.

> +
> +      <para>Before Subversion 1.6, tree conflicts could yield

s/Before/Prior to/ ?

> +        rather unexpected results. For example, if a file was
> +        locally modified, but had been renamed in the repository,
> +        running <command>svn update</command> would make Subversion
> +        carry out the following steps:</para>
> +
> +      <itemizedlist>
> +      <listitem><para>Check the file to be renamed for local
> +          modifications.</para></listitem>

These <listitem>'s should be indented relative to the <itemizedlist>.

> +
> +      <listitem><para>Delete the file at its old location, and
> +          if it had local modifications, keep an on-disk copy
> +          of the file at the old location. This on-disk copy
> +          now appears as an unversioned file in the working
> +          copy.</para></listitem>
> +
> +      <listitem><para>Add the file, as it exists in the repository,
> +          at its new location.</para></listitem>
> +      </itemizedlist>
> +
> +      <para>When this situation arises, there is the possibility
> +        that the user makes a commit without realizing that local
> +        modifications have been left in a now unversioned file in

I'm a bit of a hyphen purist; should that be "now-unversioned"?

> +        the working copy, and have not reached the repository.
> +        This gets more and more likely (and tedios) if the number

s/tedios/tedious/

> +        of files affected by this problem is large.</para>
> +
> +      <para>Since Subversion 1.6, this and other similar situations
> +        are flagged as conflicts in the working copy. As with textual
> +        conflicts, tree conflicts prevent a commit from being made

Ha!  You even said "textual conflicts" here.  :-)  Maybe that should show up
as a <firstterm> somewhere in the section that talks about those types of
conflicts?

> +        from the conflicted state, forcing the user to examine the
> +        state of the working copy for potential problems arising
> +        from the tree conflict, and resolving any such problems
> +        before committing.</para>
> +
> +      <!-- TODO: example -->
> +
> +  </sect1>
> +
> +  <!-- ================================================================= -->
> +  <!-- ================================================================= -->
> +  <!-- ================================================================= -->
>    <sect1 id="svn.tour.summary">
>      <title>Summary</title>
>  


-- 
C. Michael Pilato <cmpilato at red-bean.com> | http://cmpilato.blogspot.com/




More information about the svnbook-dev mailing list