Tobias Schäfer wrote:
>
> I agree that my suggestion is rather optimistic. On the other hand we are
> "only" talking about semantic conflicts which are also reproducible when
> simply working with files. Subversion can not possibly prevent all semantic
> conflicts but I guess it should try prevent most conflicts without to many
> false alarms.
You're right - our choice is a trade-off between convenience in the common case
and the possibility of semantic conflicts.
> To summarize this up, we have the following levels ranging from lazy over
> conservative to very-optimistic when committing property-changes to a
> directory:
>
> 1. lazy: check the revision number and bail out with an out-of-date error if
> BASE<HEAD. This is currently implemented.
> 2a) conservative: check recursively below the directory if everything is
> up-to-date regarding the contents and properties of all files and
> directories. This is what I initially asked on the user-mailing-list.
That would be an improvement and would be completely safe, so if it's
relatively easy to do we should do this first, or, at least, in considering the
further possibilities, assume that we will do it.
> 2b) less-conservative: check non-recursively below the directory if everything
> is up-to-date regarding the contents and properties of all files and that no
> files or directories have been added or deleted. This adresses your valid
> objection concerning svn:ignore and svn:externals without going recursively
> through the whole directory.
This might be reasonable as an extension. It's not so safe - people might use
a property that relates to the state of the whole sub-tree. None of the
current reserved "svn:" properties do so, but I wonder if anybody is already
using one of their own.
> 3a) optimistic: check if there are any property changes between BASE and HEAD
> and bail out with an out-of-date error if there are changes; otherwise the
> commit succeeds. This is what #1539 suggests and is what I implemented with
> my patch.
Just FYI, that wasn't my reading of the issue. I read this in the initial
comment: "HEAD's version of the directory is *identical* in terms of entries
and props." I guess you're relying on this in the third comment: "use
svn_fs_props_changed() instead of doing a revision comparison (at least I think
that would work out)".
> 4b) very-optimistic: check if the property-changes between BASE and HEAD would
> be mergable with an update and only bail out on encountering a conflict. This
> is what I described with "Further Enhancement" in my mail at the beginning of
> this thread. Note: syntactically all is safe, but sematically not.
>
> I would vote for level 2b. If we agree that 2a or 2b is disirable I am willing
> to try and provide a patch.
Note also this sentence in the initial comment in issue #1539: "We shouldn't
get an out-of-date error if we try to commit a dir-propchange, or try delete
the directory." In other words, this isn't only about prop-changes. The
complete check (2a) would be necessary before allowing deletion of the directory.
I think we ought to do 2a, preferably allowing both prop changes and deletion
of the directory. (It's fine if you just want to do it for prop changes, but
have a look and see if you can easily allow deletion at the same time.)
I don't feel comfortable with 2b unless you can convince me that it's both safe
and a worthwhile gain. "Update" is the time for being relaxed, since you can
check and fix the results at your leisure. "Commit" is the time for being
careful and accurate.
Actually, there is one scenario I can think of where 2b is a worthwhile gain:
on a very busy repository, it may be very difficult for anybody to change
properties on a root or near-root directory without this, if the time between
commits is less than the time taken to update the WC. However, that isn't
really a justification because prop changes aren't the only difficulty in that
scenario.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 11 04:12:25 2006