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

Re: Problems with property conflict callback

From: Ben Collins-Sussman <sussman_at_gmail.com>
Date: 2007-10-25 00:26:01 CEST

On 10/24/07, Mark Phippard <markphip@gmail.com> wrote:
> We are looking at supporting this in Subclipse. We are finding when
> the callback is called we are just getting paths to two files, the
> "myPath" and "theirPath". There is no basePath and no mergedPath.
> This begs a couple questions:
>
> 1) How can we do a 3-way diff without a base version of the property?

You can't. This sounds like a bug; can you give me a reproduction case?

Under the hood, there are 4 property values to play with, coming from
examining 2 propchanges: {base -> working} is the user's own
propchange, and {old -> new} is the propchange coming from the server.

The code which invokes the conflict-callback does a check that (base
== old). If those two values are not the same, then it just *doesn't*
call the callback. However, it looks like you found a case where
either base or old is simply undefined.

>
> 2) If we do #1, I do not see how we would tell SVN where the merged
> results are located for it to use.

If your conflict-callback decides to do the merge itself, it needs to
create a tmpfile somewhere with the merged result, then pass a path to
that tmpfile back in the conflct_result_t. (You also need to
'choose_merged' in the conflict_result_t.)

(This is true of both text and prop conflicts.)

>
> Adding Stefan to the cc: as I imagine he is also looking into this and
> maybe he sees different behavior or has an idea how to handle it?
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 25 00:26:12 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.