Mark Phippard wrote:
> I was trying to recreate the output of svn info from JavaHL. When an
> item has a tree conflict, the output shows something like this:
>
> Source left: (none)
> file:///blah/MyRepository/trunk/MyProject/filename.txt_at_160
> Source right: (file)
> file:///blah/MyRepository/trunk/MyProject/filename.txt_at_161
>
> It appears to get these from:
>
> /** Info on the "merge-left source" or "older" version of incoming change.
> * @since New in 1.6. */
> svn_wc_conflict_version_t *src_left_version;
>
> /** Info on the "merge-right source" or "their" version of incoming change.
> * @since New in 1.6. */
> svn_wc_conflict_version_t *src_right_version;
>
> /* Remember to adjust svn_wc__conflict_description_dup()
> * if you add new fields to this struct. */
> } svn_wc_conflict_description_t;
>
>
> These last two fields in the svn_wc_conflict_description_t struct have
> not been exposed to JavaHL in its ConflictDescriptor class. Could
> they be? I am guessing we will need a new Java type created for
> svn_wc_conflict_version_t in the process?
>
> I am just worried that when we get to the point of trying to write
> some GUI process to help people resolve conflicts we will run into
> roadblocks if we do not have access to all of the data that is
> potentially available.
I can take a look at this. I've also started to track down the test failure
introduced by r35418.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1055022
Received on 2009-01-26 16:35:57 CET