Julian Foad wrote:
> We have a bug in tree conflict code where it tries to store tree
> conflict metadata in the entries file, but, after writing it loggily and
> running the log, the cached entry in the adm_access baton is out of date
> and so attempts to read back the state (from the cache) get the wrong
> result.
I really hope I'm missing something simple. In the merge code:
svn_client/merge.c:merge_props_changed() calls svn_wc_merge_props2()
which writes prop changes to a log and then runs the log. It then
returns to its caller merge_file_changed() which goes on to pass the
adm_access to svn_wc_text_modified_p() and svn_wc_merge3().
Is that safe? It seems to me that the adm_access has out-of-date cached
properties (remember we cache some boolean property values in the
entry).
???
- Julian
> How should we handle that? Is there a "resynchronize the adm_access
> entries cache"? Should we close the adm_access baton, and, if so, is it
> in general possible to re-open it straight away? (It doesn't appear
> possible in general to re-open an access that was part of a set, due to
> ordering restrictions, though that's not totally clear.)
>
> If the answer is "You don't: You stick to loggy writes and don't do any
> reads until you've finished processing the directory" that will be a bit
> hard to swallow, but we need to know so ...
>
> Thanks in advance for any clues.
>
> Thanks,
> - Julian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-17 16:43:18 CET