On Fri, 2010-07-09 at 09:52 +0200, Daniel Näslund wrote:
> Hi!
>
> The diff callbacks for handling text have revision arguments. The prop
> callbacks don't.
>
> I'm creating diff headers for the cases when we only have property
> changes. When creating those diff headers I need revisions. Since the
> prop diff callback doesn't have revision arguments I'm using the
> revision fields in struct diff_cmd_baton. Here's what the doc string says
> about those fields.
>
> [[[
> /* These are the numeric representations of the revisions passed to
> svn_client_diff5, either may be SVN_INVALID_REVNUM. We need these
> because some of the svn_wc_diff_callbacks4_t don't get revision
> arguments.
>
> ### Perhaps we should change the callback signatures and eliminate
> ### these?
> */
> svn_revnum_t revnum1;
> svn_revnum_t revnum2;
> ]]]
>
> But they don't match the revisions returned by the diff callbacks.
> Here's the output from diff_content_changed() comparing what the baton
> fields says and what the revision argument says (from diff_tests 32):
>
> $ svn di -r 1 | grep DBG
>
> DBG: diff.c: 692: btn->rev1 1, rev1 0, btn->revn2 -1, rev2 3
> DBG: diff.c: 692: btn->rev1 1, rev1 0, btn->revn2 -1, rev2 3
Hi Daniel.
For rev2, it looks like the caller is providing SVN_INVALID_REVNUM to
mean HEAD, and then something is discovering the current value of HEAD
is 3, but is not updating "btn->revn2" with that information. I think,
if possible, the code that discovers the actual HEAD revision number
should store it in the baton so that everything else can refer to it.
If this discovery happens on the client side, that should be possible.
- Julian
> I was under the impression that a revision is something fixed (after
> we've done the peg revision dance). Any suggestion to why the revisions
> may differ?
>
> Sidenote: svn diff -r PREV:BASE shows 'working copy' as revision in the
> diff label. I'm thinking 'working copy' must involve the working
> changes.
>
> Thanks,
> Daniel
Received on 2010-07-09 13:38:23 CEST