[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: switch --relocate fails on deleted dir in mixed-rev WC

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-10-12 13:04:50 CEST

Philip Martin wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>>- if (recurse && (entry->kind == svn_node_dir))
>>+ if (recurse && (entry->kind == svn_node_dir)
>>+ && ((! entry->deleted && ! entry->absent)
>>+ || (entry->schedule == svn_wc_schedule_add)
>>+ || (entry->schedule == svn_wc_schedule_replace)))
>> {
>> svn_wc_adm_access_t *subdir_access;
>> const char *subdir = svn_path_join (path, key, pool);
>>I'm rather unsure of the exact meanings and combinations of "absent"
>>and "deleted" and "schedule", and am worried by other bits of code
>>using different tests such as the following:
> 'schedule="delete"' indicates that an existing item will be deleted at
> the next commit, think 'svn rm wc/foo'.
> 'schedule="add"' indicates that a new item will be added at the next
> commit, think 'svn add wc/foo'.
> 'schedule="replace"' indicates both of the above, think 'svn rm wc/foo'
> followed by 'svn add wc/foo'.
> 'deleted="true"' indicates that the entry was scheduled for deletion
> and subsequently committed, but that the parent directory has not been
> updated and so is at a revision that would otherwise contain the
> deleted item, think 'svn rm wc/foo' followed by 'svn ci wc'
> 'absent="true"' indicates that mod_authz_svn doesn't allow read access
> to that item so it's not physically present in the working copy.

Yes, their individual meanings all sound simple enough at first reading, but in
combination, how, for instance, do you get a directory "deleted" with

> Your change looks correct to me.


>>> /* Remove any deleted or missing entries. */
>>> for (hi = apr_hash_first (pool, entries); hi; hi = apr_hash_next (hi))
>>> {
>>> /* Any entry still marked as deleted (and not schedule add) can now
>>> be removed -- if it wasn't undeleted by the update, then it
>>> shouldn't stay in the updated working set. Schedule add items
>>> should remain.
>>> */
>>> if (current_entry->deleted)
>>> {
>>> if (current_entry->schedule != svn_wc_schedule_add)
>>> svn_wc__entry_remove (entries, name);
>>Can someone explain why that doesn't consider "replace"? If it's a
>>bug, can we construct a test for it?
> Not a bug. If the item is 'deleted="true"' the delete has already
> been committed, so that item can't be 'schedule="delete"' as it no
> longer exists, and so 'schedule="replace"' cannot happen.

I'm failing to see how this is different from the fix above.

- Julian

> That bit of code was the subject of much discussion when written and
> it's still one of the hairy bits of libsvn_wc. I think it relies on
> the 'incomplete="true"' processing to make it robust in the face of an
> interrupted update, but I would not like to say for certain that it
> always works.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 12 13:05:53 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.