subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Zhakov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SVN-2118) property merging unnecessarily strict
Date Fri, 09 Oct 2015 22:15:05 GMT

    [ 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)

Mime
View raw message