"C. Michael Pilato" <email@example.com> writes:
> Philip Martin <firstname.lastname@example.org> writes:
>> I supose we could catch/ignore the error somewhere (libsvn_ra_dav
>> perhaps) if that's the only thing going wrong. I don't understand the
>> problem sufficiently to determine whether ignoring the error is safe.
> I believe it would be fine for libsvn_ra_dav to catch and ignore this
> error. It's just trying to write an unnecessary cache to save itself
> some work in future operations.
> Or we could go all extreme and simply turn off the resource walk for
> switches in 1.2. This way, the wcprop callback would never get
> invoked during a switch, and you shouldn't see any of these problems.
> This would:
> - fix the compatibility problem.
> - speed up ra-dav switches.
> - add a few small extra network turnarounds to the first ra-dav
> operation that needs a vsn-rsrc-url for each path in the tree
> (but afterwards it would be cached). and actually, it's not even
> that bad, but because any paths touched during an update would
> get their vsn-rsrc-urls cached at no additional cost.
> We could always re-enable the resource walk again in the future if we
> wanted to.
Now I'm worried that r12006 doesn't fix the problem it's supposed to
fix. Consider the following (I'm using a schedule add file because we
don't have items with suitable names in the Subversion repo):
$ svn co https://svn.collab.net/repos/svn/trunk/tools qq
$ touch qq/random-commits.py
$ svn add qq/random-commits.py
$ svn sw https://svn.collab.net/repos/svn/branches/1.1.x/tools/dev qq/dev
svn: 'qq/gnuify-changelog.pl' is not under version control
It's hit my new check on gnuify-changelog.pl and that's good,
previously it would have written a spurious file in qq/.svn/wcprops.
However it didn't stop on random-commits.py because a suitable
versioned item exists, so that file has switched wcprops even though
it didn't get switched:
$ cat qq/.svn/wcprops/random-commits.py.svn-work
That might be harmless for this schedule add file, but if that were a
committed file things would fall over.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Dec 3 16:30:31 2004