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