[jira] [Comment Edited] (SVN-2118) property merging unnecessarily strict

["Ivan Zhakov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SVN-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14920921#comment-14920921 ] 

Ivan Zhakov edited comment on SVN-2118 at 10/9/15 10:14 PM:
------------------------------------------------------------

The reason for this limitation isn't because we're lazy, it's because it *is* a theoretical problem,  discussed years and years ago.  It's even mentioned in the svn book.

Suppose HEAD == 15, and you have working revision 10 of a directory in your WC.  You make a {{propchange}} on the directory, and commit.  Suppose the client allowed the commit to happen, and suppose the repository also allowed it.  That is, the server notices that the properties on r15 of the directory are the same as those on r10, so your change merges smoothly without destroying data you've not yet seen.

So what happens then?  What do you have in the working copy after the commit?  You certainly don't have r10 of the directory anymore;  the props are different.  It's not theoretically sound to say that you have r15 of the directory either... somebody might have added or deleted children between r10:r15.

I suppose there are workarounds for this... maybe... hmm.

One workaround is that the server can reject the commit if you're trying to commit a {{dir-prop-change}} and *either* the props or dirents don't match.   Just extend our definition of "out of date".  If r10 and r15 of the directory truly have the same props and entries, then it's perfectly correct for libsvn_wc to mark your WC directory as 'r15' after the commit succeeds.

Another workaround is to stay somewhat loose about defining out-of-dateness, and make libsvn_wc mark the directory as r15, but 'incomplete' after the commit succeeds.  This tells libsvn_wc to not trust the WC dir's list of entries, and do to a low-confidence report on the next update.

So heck, maybe this really is something we can fix, now that we have a notion of 'incomplete' dirents.


was (Author: sussman):
{noformat:nopanel=true}
The reason for this limitation isn't because we're lazy, it's because it *is* a theoretical problem, 
discussed years and years ago.  It's even mentioned in the svn book.

Suppose HEAD == 15, and you have working revision 10 of a directory in your WC.  You make a 
propchange on the directory, and commit.  Suppose the client allowed the commit to happen, and 
suppose the repository also allowed it.  That is, the server notices that the properties on r15 of the 
directory are the same as those on r10, so your change merges smoothly without destroying data 
you've not yet seen.

So what happens then?  What do you have in the working copy after the commit?  You certainly don't 
have r10 of the directory anymore;  the props are different.  It's not theoretically sound to say that you 
have r15 of the directory either... somebody might have added or deleted children between r10:r15.

I suppose there are workarounds for this... maybe... hmm.

One workaround is that the server can reject the commit if you're trying to commit a dir-prop-change 
and *either* the props or dirents don't match.   Just extend our definition of "out of date".  If r10 and 
r15 of the directory truly have the same props and entries, then it's perfectly correct for libsvn_wc to 
mark your WC directory as 'r15' after the commit succeeds.

Another workaround is to stay somewhat loose about defining out-of-dateness, and make libsvn_wc 
mark the directory as r15, but 'incomplete' after the commit succeeds.  This tells libsvn_wc to not trust 
the WC dir's list of entries, and do to a low-confidence report on the next update.

So heck, maybe this really is something we can fix, now that we have a notion of 'incomplete' dirents.

{noformat}


> property merging unnecessarily strict
> -------------------------------------
>
>                 Key: SVN-2118
>                 URL: https://issues.apache.org/jira/browse/SVN-2118
>             Project: Subversion
>          Issue Type: Improvement
>          Components: libsvn_fs
>    Affects Versions: all
>            Reporter: Karl Fogel
>            Priority: Critical
>             Fix For: unscheduled
>
>
> Committing a property change to a directory fails if that directory is out-of-date, even if it's only out-of-date due to bubble-up semantics.  This can be a bit tiresome; from the user's point of view, why is the property change being prohibited?  It's hard to justify.
> The shell script below demonstrates the problem.
> I think there's some reason we have this limitation -- no theoretical showstopper, just ease of implementation or something like that.  Might be time to reexamine the tradeoff, though.
> {noformat:nopanel=true}
> ============= cut here ======= 8-< ======= cut here ============
> #!/bin/sh
> # Edit these as necessary:
> SVN=${HOME}/src/subversion/subversion/clients/cmdline/svn
> SVNADMIN=${HOME}/src/subversion/subversion/svnadmin/svnadmin
> # Clean up from a previous run.
> rm -rf wc repos
> # Set up the repository.
> ${SVNADMIN} create repos
> ${SVN} mkdir -m "Create a top-level directory." file://`pwd`/repos/trunk
> ${SVN} mkdir -m "Create a subdir." file://`pwd`/repos/trunk/subdir/
> # Create a working copy.
> ${SVN} co file://`pwd`/repos/trunk/ wc
> # Create a file in a subdir, just to make a change.
> cd wc/subdir
> echo "A file." > somefile
> ${SVN} add somefile
> ${SVN} ci -m "Add somefile."
> cd ..
> # Try to commit a property on the top-level dir.  It should fail
> # because out of date.
> ${SVN} propset "myprop" "myval" . 
> ${SVN} ci -m "Attempting to committing myprop on top dir."
> echo ""
> echo "That failure was expected.  Now we update and try again:"
> ${SVN} up
> ${SVN} ci -m "Attempting to committing myprop on top dir."
> echo ""
> echo "It succeeded this time, as expected."
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)