I've got a few bits and bats to add to this one..
Bert Huijben wrote:
> I tried to reopen this issue on the developer list in the
> "Issue #3119 - File '...' already exists" (Regression since 1.5.0)" thread
> on the development list.
> We did some research but the thread died on the major problem that we can't
> reproduce it at will.
In contrast I find that Karl's reproduction script is a 100% reliable.
> To fully resolve this issue we really need a script that can reproduce the
> issue every (or at least some of the) time.
I attach my hacked version of Karl's script - this is just the current
as-is state of it the way I am using it in my set up for your ref. Also
attached is one I cooked up that *doesn't* reproduce the fault, but I
can't work out the crucial difference...
> I'm just guessing but maybe the following factors might help us:
> * Which server versions have the issue? (1.5.x?) (1.4.x?)
> * The issue was reported only to client versions after 1.5.0. Did somebody
> reproduce it with a trunk build?
Yep reproducible with trunk.
According to the previously mentioned thread:
rhuijben writes 'It looks like r31692 introduced the regression
described in issue #3119,'...
Said rev was merged to 1.5.x at 31799 and I can confirm that the bug is
there with 31799 and not with 31798
>> Karl Fogel wrote on Sat, 11 Oct 2008 at 18:25 -0400:
>>> the following code should get a "file not found" error (i.e., an HTTP
>>> 404) when it probes for the existence of the file we're about to add,
>>> but doesn't -- instead, it's as though the file already exists:
>>> svn_ra_neon__resource_t *res;
>>> svn_error_t *err = svn_ra_neon__get_starting_props(&res,
before the offending rev this used file->rsrc->url where it now uses
>>> if (!err)
>>> /* If the PROPFIND succeeds the file already exists */
>>> return svn_error_createf(SVN_ERR_RA_DAV_ALREADY_EXISTS,
>>> Note that in the reproduction recipe, if you insert an "svn up
>>> right before the final svn cp in the reproduction recipe, then none
>>> this weirdness happens, and the bug doesn't reproduce.
>>> So why does the file claim to be present in the txn already? And why
>>> does updating the whole working copy to r2 (instead of having a mixed
>>> r1/r2 working copy) cause the repository filesystem to correctly
>>> that the file is not there?
If the w/c is updated before the final copy then commit_add_file doesn't
get called. It may be that if the above mentioned code was called, it
would still malfunction.
At the risk of adding to the confusion I think I've seen this problem
from a non-mixed-rev w/c
Changing to using ra_serf is a good work around (for me and my
colleagues anyway) - is this worth noting in the issue tracker?
Received on 2008-12-29 08:17:02 CET