work-in-progress tree conflicts diff, please comment

Stefan Sperling stsp at elego.de
Tue Jan 6 04:46:31 CST 2009


On Tue, Jan 06, 2009 at 04:55:09AM -0500, C. Michael Pilato wrote:
> 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.

Thanks!

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

OK. So this is probably not working in my case because the delete
happens before the add.

Should we add a footnote that explains the circumstances or just ignore
this and hope no one will ask questions?

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

Done.

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

Great, taken.

I was wondering if a tag like <firstterm> existed, just didn't know
what it was called. Is there a list of available tags somewhere?
There was no such list in the DocBook-Demystification-HOWTO.

> > +
> > +      <para>Before Subversion 1.6, tree conflicts could yield
> 
> s/Before/Prior to/ ?

Yup.

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

Yes, I wondering... Check ch06-server-configuration.xml, that's were
I got this indentation from -- we might want to fix it there, too.

> > +
> > +      <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"?

I don't really know hyphentation rules of English...
I'll trust your instinct as a native speaker and add the hyphen.
 
> > +        the working copy, and have not reached the repository.
> > +        This gets more and more likely (and tedios) if the number
> 
> s/tedios/tedious/

Oh, I was just trying to avoid British spelling :)
Fixed. (Note that Vim's spell-checker didn't complain about 'tedios'.)

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

I'll look into that and make a separate diff.

Thanks heaps Michael!

I'll wait a few more hours, and commit the diff below if no more
feedback comes in. We can still fix up remaining issues in subsequent
commits.

Stefan

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,67 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <!-- ================================================================= -->
+  <sect1 id="svn.tour.treeconflicts">
+    <title>Dealing with Structural Conflicts</title>
+      
+      <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
+        files at their new location. 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>
+
+      <para>Prior to Subversion 1.6, tree conflicts could yield
+        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>
+
+        <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
+        the working copy, and have not reached the repository.
+        This gets more and more likely (and tedious) if the number
+        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
+        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>
 




More information about the svnbook-dev mailing list