[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Fwd: svn commit: r33855 - in branches/tree-conflicts-notify/subversion: include libsvn_client libsvn_wc svn tests/cmdline tests/cmdline/svntest]

From: Stephen Butler <sbutler_at_elego.de>
Date: Thu, 23 Oct 2008 14:48:09 +0200

Quoting Julian Foad <julianfoad_at_btopenworld.com>:

> On Thu, 2008-10-23 at 13:31 +0200, Neels J Hofmeyr wrote:
>>
>> Stephen Butler wrote:
>> > Quoting "Neels J. Hofmeyr" <neels_at_elego.de>:
>> >
>> >> 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?
>> >
>> > Yes. The logs appear to be executed only at delete_entry(),
>> > close_directory(), or when the user cancels. So we'll have to
>> > pass around a local result from check_tree_conflict().
>> >
>> >>
>> >> 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.
>> >
>> > Try this, from subversion/libsvn_wc/status.c on trunk, in
>> get_dir_status().
>> >
>> > {
>> > svn_wc_conflict_description_t *tree_conflict;
>> > SVN_ERR(svn_wc_get_tree_conflict(&tree_conflict,
>> > svn_path_join(path, entry,
>> subpool),
>> > adm_access, subpool));
>> > if (tree_conflict)
>> > {
>> > [...]
>> > }
>> > }
>> >
>> > This works even for victims that don't exist (neither in the working
>> > copy nor in the repo). Our svn_wc_conflicted_p2() requires a valid
>> > entry, which means it simply can't do the job.
>>
>> Cool, thanks!
>
> But that doesn't enable us to read back the conflict state immediately
> after loggy-writing it, does it?

No. We need check_tree_conflict() to tell us whether it found a conflict.
Then we'll modify the output, in callbacks that print output immediately.
For open_file() and open_directory(), we'll stash the tree_conflicted
boolean in the file or dir baton, for use when the item's output is
printed upon closing it.

>
>> > I suggest we un-deprecate the original svn_wc_conflicted_p() and use
>> > it for reading text and prop conflict state only. And use the existing
>> > svn_wc_get_tree_conflict() to read tree conflict state.

Any arguments against this?

Thanks,
Steve

-- 
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
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 14:48:26 CEST

This is an archived mail posted to the Subversion Dev mailing list.