Re: Error when creating tags from working copy

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.
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=985
> 284
>
> 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

[snip]
>>
>> Karl Fogel wrote on Sat, 11 Oct 2008 at 18:25 -0400:
[snip]
>>> 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,
>>> file->cc-
>>> ras,
>>> file->rsrc-
>>> wr_url,
>>> NULL,
>> workpool);

before the offending rev this used file->rsrc->url where it now uses
file->rsrc->wr_url

>>> if (!err)
>>> {
>>> /* If the PROPFIND succeeds the file already exists */
>>> return svn_error_createf(SVN_ERR_RA_DAV_ALREADY_EXISTS,
[snip]

>>>
>>> Note that in the reproduction recipe, if you insert an "svn up
>> Data/wc"
>>> right before the final svn cp in the reproduction recipe, then none
>> of
>>> 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
>> answer
>>> 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?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=994684