On Thu, 2008-10-23 at 10:32 +0200, Neels J. Hofmeyr wrote:
> Hi tree-conflicts folks,
>
> could you please scroll over this and see if you can remotely relate to what
> is going on there? Branch tree-conflicts-notify, r33855.
>
> Particularly, I see that right after calling check_tree_conflict(), I can't
> get the tree-conflict state by doing
> [[[
> /* Find out whether it's a tree conflict victim. */
> if (tree_conflicted_p != NULL)
> {
> svn_wc_conflict_description_t *conflict;
> SVN_ERR_ASSERT(adm_access != NULL);
> path = svn_path_join(dir_path, entry->name, subpool);
> SVN_ERR(svn_wc_get_tree_conflict(&conflict, path, adm_access, subpool));
> *tree_conflicted_p = (conflict != NULL);
> }
> ]]]
> (I try to do that in svn_wc_conflicted_p2(), called from
> subversion/libsvn_wc/update_editor.c, e.g. line 2721 on the branch),
> apparently because the tree-conflict reporting is loggy?
Hmm. Yes. A tree conflict is raised by writing commands with
svn_wc__loggy_entry_modify() into a log file which will modify the entry
later. If we then call svn_wc_conflicted_p2() it looks at the (not yet
modified) entry.
I don't know if this is just something we must accept or if we're doing
it wrong. For now, I would accept it and get the info another way like
you are doing.
WC gurus, are we reading and writing entries properly? Should we flush
(write and then run) the log file before calling anything that queries
the info we've just written? Should we not be using loggy writes here?
- Julian
> If you guys know how best to get the tree-conflicted state of a node, let me
> know. At the moment I'm making check_tree_conflict() return a value to
> explicitly indicate a conflict to the caller. But it would be nice to have
> svn_wc_conflicted_p2() work as advertised on the branch.
>
> Thanks,
> ~Neels
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-23 13:00:19 CEST