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

Re: Fixing blame misalignment for >1m revs - some questions

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Wed, 16 Jun 2010 21:32:56 +0200

On Wed, Jun 16, 2010 at 3:58 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> Johan Corveleyn wrote:
>> On Wed, Jun 16, 2010 at 1:11 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
>> > Note that the caller can request a blame where the "end" revision is the
>> > "WORKING" pseudo-revision, so be careful not to confuse the reader when
>> > documenting this new "end revision number" parameter which is a revision
>> > number as determined from the repository and which will not include the
>> > "WORKING" pseudo-revision.  (Maybe we should also pass a parameter that
>> > provides this information: "svn_boolean_t
>> > range_includes_working_version"?)
[...]
> On the other hand, this is information that the client already knows and
> can pass via the "baton", so it doesn't need to be passed through a
> separate argument to this callback.

Ah, yes indeed. In fact it's already passed via the baton (at least in
blame-cmd's case). Inside svn_cl__blame, the blame_baton_t gets a
reference to the opt_state. And then there is the following piece of
code, right before svn_client_blame5 is called:

[[[
      if (end_revision_unspecified)
        {
          if (peg_revision.kind != svn_opt_revision_unspecified)
            opt_state->end_revision = peg_revision;
          else if (svn_path_is_url(target))
            opt_state->end_revision.kind = svn_opt_revision_head;
          else
            opt_state->end_revision.kind = svn_opt_revision_working;
        }
]]]

So I guess that should be ok.

Cheers,

-- 
Johan
Received on 2010-06-16 21:33:33 CEST

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.