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

Re: [PATCH] In status -u, use target as anchor if target is a versioned directory.

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: 2007-04-10 23:15:25 CEST

Malcolm Rowe wrote:
> On Tue, Apr 03, 2007 at 05:08:48PM +0200, Lieven Govaerts wrote:
>> Malcolm Rowe wrote:
>>> If you're right (that this is okay from a correctness standpoint, and
>>> that it's more efficient), this logic should be inlined directly into
>>> svn_wc_adm_open_anchor(), I'd have thought.
> Anyway, svn_wc_adm_open_anchor() is trying to solve exactly that
> problem, so if you have a generic fix, I'd put it there. (And it it's
> not generic, it may not be appropriate for 'status -u' either, if we've
> missed something).
> Ah, one possibility where {anchor wc/, target A/} might be necessary is
> when A/ is schedule-deleted. What does 'status -u' do in that case?
I changed the behavior of svn_wc_adm_open_anchor() and ran the full test
suite with this result:

FAIL: update_tests.py 21: update child before parent of a deleted tree
FAIL: update_tests.py 22: update a schedule-add directory
FAIL: copy_tests.py 9: move and revert a directory
FAIL: copy_tests.py 24: wc to wc copy with deleted=true items

Basically the issue is in write operations (update, revert) on
directories somewhere (at least one level) deep in the working copy. To
cover for renames, schedule-add, schedule-delete etc., svn needs access
the target entry in its parent directory.

While I could technically limit the behavior change in
svn_wc_adm_open_anchor() to write operations only, its probably best to
leave it the same for both operations; I'll see if I can handle that in
the 'status --depth' patch I'm working on.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 10 23:15:52 2007

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.