[svnbook commit] r3398 - trunk/src/en/book

stsp noreply at red-bean.com
Tue Jan 6 10:00:38 CST 2009

Author: stsp
Date: Tue Jan  6 10:00:38 2009
New Revision: 3398

* src/en/book/ch02-basic-usage.xml
  (svn.tour.treeconflicts): New section that introduces
   the basics of tree conflicts. Still needs to be extended
   with actual examples.

Review and great input by: cmpilato
                           Neels Hofmeyr


Modified: trunk/src/en/book/ch02-basic-usage.xml
--- trunk/src/en/book/ch02-basic-usage.xml	(original)
+++ trunk/src/en/book/ch02-basic-usage.xml	Tue Jan  6 10:00:38 2009
@@ -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">

More information about the svnbook-dev mailing list