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

stsp noreply at red-bean.com
Thu Jan 8 07:50:36 CST 2009


Author: stsp
Date: Thu Jan  8 07:50:36 2009
New Revision: 3399

Log:
* src/en/book/ch02-basic-usage.xml
  (svn.tour.treeconflicts): Move material related to 1.5
   into a side-bar. Also, we don't "force" users to resolve
   conflicts, so phrase it as "giving the opportunity"
   instead. Also, add a footnote explaining that files
   with textual conflicts can of course be committed with
   their conflict markers intact, so when we say Subversion
   was "forcing" users to resolve text conflicts, this has
   to be taken with a grain of salt.

Suggested by: julianfoad
(footnote added by myself)


Modified:
   trunk/src/en/book/ch02-basic-usage.xml

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	Thu Jan  8 07:50:36 2009
@@ -2290,7 +2290,10 @@
       <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>
+        changes before you can commit.<footnote><para>Well, you could mark
+        files containing conflict markers as resolved and commit them,
+        if you really wanted to. But this is rarely done in practice.</para>
+        </footnote></para>
         
       <para>But what happens if your collaborators move or delete a file
         that you are still working on? Maybe there was a miscommunication,
@@ -2303,40 +2306,46 @@
         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>
+      <sidebar>
+        <title>Tree conflicts prior to Subversion 1.6</title>
+
+        <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.</para>
+
+      </sidebar>
+
+      <para>As with textual conflicts, tree conflicts prevent a commit
+        from being made from the conflicted state, giving the user the
+        opportunity 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 -->
 




More information about the svnbook-dev mailing list