"Ben Collins-Sussman" <sussman@red-bean.com> writes:
> The question is: why the wc-searching routine
> (update_editor.c:locate_copyfrom()) think that it's found the correct
> version of the file, when it's not? Answer: it seems to be getting
> stale svn_wc_entry_t information. It's reading a couple of entries
> files from disk, rather than from a more recent adm_access set still
> held in memory, and getting an incorrect (stale) last-changed-rev
> value. From poking around in gdb, it seems that the entry_t's which
> are write-cached in memory are correct -- they have the proper
> last-changed-rev values, but simply aren't flushed to disk yet.
>
> I attempted to solve this by passing in the edit_baton->access_set to
> the searching routine, but it's not fixing the problem. I've attached
> my patch-in-progress below. Can we get some more eyes on this
> problem?
I think there are two bugs here. I believe it is wrong for
locate_copyfrom to use a read-only snapshot of the working copy, your
patch to pass an access baton looks like the right thing to do,
although I think that the _try calls should take write locks. However
that's not what is causing the current failure.
The reason that locate_copyfrom thinks it has the right file is that
when alpha first gets added it has committed-rev=1 and that meets the
conditions required by locate_copyfrom. This happens because alpha
itself has copyfrom info and update_editor.c:add_file_with_history
calls eb->fetch_func to get gamma@1 from the repository and then there
is a bit of code that does:
/* Loop over whatever base-props we have in memory, faking change_file_prop()
calls against the file baton. */
for (hi = apr_hash_first(pool, base_props); hi; hi = apr_hash_next(hi))
{
const void *key;
void *val;
const char *propname;
svn_string_t *propval;
apr_hash_this(hi, &key, NULL, &val);
propname = key;
propval = val;
SVN_ERR(change_file_prop(tfb, propname, propval, pool));
}
which transfers the gamma@1 props to the new alpha, including
committed-rev=1. Later on alpha will get corrected to have
committed-rev=3 but before that something else happens to look for
alpha@1.
Perhaps properties like committed-rev should be filtered out of then
above loop? Perhaps only regular props should be transferred?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 14:02:25 2007