work-in-progress tree conflicts diff, please comment
Stefan Sperling
stsp at elego.de
Tue Jan 6 03:25:22 CST 2009
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!
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?
Thanks,
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,71 @@
<!-- ================================================================= -->
<!-- ================================================================= -->
<!-- ================================================================= -->
+ <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
+ 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>
+
+ <para>Before 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 tedios) 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recipe.sh
Type: application/x-sh
Size: 853 bytes
Desc: not available
URL: <http://www.red-bean.com/pipermail/svnbook-dev/attachments/20090106/92b0290f/attachment.sh>
More information about the svnbook-dev
mailing list