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

Re: [PATCH] Op-depth for copies - fixing lock_tests.py 40 - in progress

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Tue, 23 Nov 2010 18:00:40 +0000

Philip or anyone: my main concern here is whether I'm taking a sensible
approach here in throwing away the new all-in-one copy and going back to
the old code here. Any comments? Anyway here's today's iteration of
this patch.

More below...

On Mon, 2010-11-22, Julian Foad wrote:
> lock_tests.py 40 fails because my WC-to-WC copy code doesn't reset files
> to read-write on disk when it copies them if svn:needs-lock was set on
> the source, which the old code did; instead, it just copies exactly
> what's there.
>
> The attached patch is where I have got to today, attacking that from the
> angle of abandoning my all-in-one approach now that Philip's made the
> WC-to-WC code handle op-depth automatically. I try to extend that to
> cover this case.
>
> As it says in the log msg, it fixes lock_tests.py 40 but breaks
> copy_tests.py 47. I haven't time today to go further with seeing why.

The attached version 2 of this patch doesn't break copy_tests 47 or
anything else, AFICT; still running tests now.

In patch version 1, db_op_copy() was inserting 'incomplete' nodes for
children of a copied added dir, even though its children were only local
adds, so that was wrong. Instead I am making it use a new function
"gather_repo_children()" which only reads children at the same op-depth
as the specified parent dir. I *think* that would give the correct set
of children that need to be marked as incomplete. At least it returns
no children when there are only local adds, which is the case in
lock_tests 40.

I want to split this patch up and commit the refactoring of
gather_children() as a separate patch first, then the behaviour changes.

- Julian

Received on 2010-11-23 19:01:25 CET

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.