Hi,
After some research on an AnkhSVN issue I discovered the issue that I
documented last weekend as issue #3659.
Since Subversion 1.5 added depth support on the update handler, we have a
bug where a working copy thinks it knows all entries of a directory, but
where the repository knows more entries. Future updates don't retrieve these
entries and in many cases error out on non existing files.
Let's assume I have a repository with a subdirectory.
$ svn up wc/subdir
<snip>
Updated to r70.
<Day later>
# Fetch only the new properties on that subdirectory
$ svn up --depth empty wc/subdir
<snip>
Updated to r80.
<Day later>
$ svn up wc
<snip>
Updated to r90.
And now your working copy doesn't show the new files and directories you
colleagues *added* in r71-r80.
The reason we miss these additions is that our update process identifies the
working copy state by the revision of the parent and possibly specific
revisions of the children. (And some other details like depth, etc.). But in
this case we updated the parent, but not its child-list. So the workingcopy
description of the parent is incomplete and the repository doesn't know that
it does send the new information.
In a few other cases of mixed revision working copies, we applied specific
fixes.
* Delete operations that are committed leave a 'deleted' entry (WC-NG:
not-present marking in BASE)
* If an update fails halfway we keep the directory in an incomplete state
* If a directories ambient depth is less than infinity, this is communicated
in a special way to the server.
But, this specific case here falls right through all these features. Only
the repository knows about the additions (as the update is driven with a
smaller depth), but the repository doesn't get a request for them.
This is a pretty fundamental issue, that touches the original design of
sparse working copies. And when the UI of the feature was discussed in 2007
there was some talk about some of these cases, but this issue was not found.
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=926
233
It will be pretty hard to resolve this issue while keeping the current
non-recursive update behavior. I see a few options to resolve this:
(<smaller> is a depth smaller than the ambient depth)
* On 'svn up --depth <smaller>' store a new boolean on the directory to
indicate that its child-list is incomplete.
* On 'svn up --depth <smaller>' actually perform a depth a bit deeper and
add deleted entries for the missed nodes. (WC-NG: BASE not-present nodes)
* On 'svn up --depth <smaller>' set the ambient depth to '<smaller>' but
keep the existing entries. (Recoverable via --set-depth infinity in the next
update)
* Deny 'svn up --depth <smaller>'
Note that all this doesn't apply to the --set-depth options as these keep
the ambient value
[For the next AnkhSVN release we will be implementing the 'deny svn up
--depth <smaller>' on the client layer, but I think this issue should be
fixed in Subversion for a future version.]
Bert
Received on 2010-02-02 13:04:32 CET