You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2009/03/02 16:01:07 UTC

RE: svn commit: r36232 - trunk/www

> Author: stsp
> Date: Sun Mar  1 15:06:04 2009
> New Revision: 36232
> 
> Log:
> * www/svn_1.6_releasenotes.html
>   (new-feature-compatibility-table): Add entry about tree conflicts.
> 
> Modified:
>    trunk/www/svn_1.6_releasenotes.html
> 
> Modified: trunk/www/svn_1.6_releasenotes.html
> URL: http://svn.collab.net/viewvc/svn/trunk/www/svn_1.6_releasenotes.html?pathrev=36232&r1=36231&r2=36232
> ==============================================================================
> --- trunk/www/svn_1.6_releasenotes.html	Sun Mar  1 14:48:23 2009	(r36231)
> +++ trunk/www/svn_1.6_releasenotes.html	Sun Mar  1 15:06:04 2009	(r36232)
> @@ -110,6 +110,13 @@ cannot necessarily compile or run agains
>      <td>any</td>
>      <td>any</td>
>      <td></td></tr>
> +  <tr>
> +    <td><a href="#tree-conflicts">tree-conflicts</a></td>
> +    <td>1.6</td>
> +    <td>1.6</td>
> +    <td>any</td>
> +    <td>Using servers older than 1.6 is possible, but some kinds
> +      of conflicts will not be detected.</td></tr>
>  </table>

Is it documented what type of conflicts will not be detected?  I have been telling people they do not need 1.6 on the server.

I am using the tigris web UI to reply.  Not sure how this will work.

Thanks

Mark

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1256803

Re: svn commit: r36232 - trunk/www

Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 02, 2009 at 08:01:07AM -0800, Mark Phippard wrote:
> > Author: stsp
> > Date: Sun Mar  1 15:06:04 2009
> > New Revision: 36232
> > 
> > Log:
> > * www/svn_1.6_releasenotes.html
> >   (new-feature-compatibility-table): Add entry about tree conflicts.
> > 
> > Modified: trunk/www/svn_1.6_releasenotes.html
> > 
> > Modified: trunk/www/svn_1.6_releasenotes.html URL:
> > http://svn.collab.net/viewvc/svn/trunk/www/svn_1.6_releasenotes.html?pathrev=36232&r1=36231&r2=36232
> > ==============================================================================
> > --- trunk/www/svn_1.6_releasenotes.html	Sun Mar  1 14:48:23 2009
> > (r36231) +++ trunk/www/svn_1.6_releasenotes.html	Sun Mar  1
> > 15:06:04 2009	(r36232) @@ -110,6 +110,13 @@ cannot necessarily
> > compile or run agains <td>any</td> <td>any</td> <td></td></tr> +
> > <tr> +    <td><a href="#tree-conflicts">tree-conflicts</a></td> +
> > <td>1.6</td> +    <td>1.6</td> +    <td>any</td> +    <td>Using
> > servers older than 1.6 is possible, but some kinds +      of
> > conflicts will not be detected.</td></tr> </table>
> 
> Is it documented what type of conflicts will not be detected?

It is now, see below :)

> I have been telling people they do not need 1.6 on the server.

When using a pre-1.6 server, the dreaded "double-delete" problem
can still happen.

Suppose you want to delete file /trunk/foo.
Your fellow developer has decided to rename /trunk/foo to /trunk/bar.

You are using svn-1.6, the server is using svn-1.5, it does not
matter what your fellow developer is using.

Your fellow developer gets to commit first.

Now you want svn to warn you about this. It should force you to update
your working copy (since it is out of date), and upon update, a tree
conflict should be flagged in your working copy.

But with pre-1.6 servers, you can commit your deletion without being
forced to update your working copy first. This is because pre-1.6 servers
will allow double-deletions, because they treat them as a no-op, and will
even happily create completely empty revisions if the only operation you
commit is the deletion of /trunk/foo.

The "workaround" is racy: Run svn update before you commit.

The proper fix is to update your server to 1.6, so that the deletion of
an already deleted file causes the commit to fail with an "out of date" error.

> I am using the tigris web UI to reply.  Not sure how this will work.

It did work fine.

Stefan