Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?

On Wed, Mar 26, 2008 at 11:06 AM, Kamesh Jayachandran <kamesh_at_collab.net> wrote:
> > this cannot just be hidden in the method interface?
>
> No. End user has a freedom to say what youngestRevision object is.
>
> If he passes youngestRevision as null it means, he is not interested in
> the "youngestRevision 'check/cache'".
>
> If he passes youngestRevision as Revision.Number(5) he want to get saved
> from any HEAD beyond r5, API will give just give 5.
>
>
> If he passes youngestRevision as Revision.Number(-1) and other revision
> as Revision.HEAD, HEAD is evaluated and youngestRevision is set as
> evaluated new revision say r16. So that he can pass youngestRevision for
> further calls to the same API.

Can you explain some more how or why a function like this needs to be
exposed to a user? If I already have a revision number of 5, why do I
need to call a method to give me the same number back? I can sort of
understand wanting an API that tells me the youngest revision, but I
do not understand why or when I would ever need something else.

Maybe the underlying native API you want to call supports this
functionality and there are internal cases where it is used or needed,
but before we expose this to users via JavaHL I think we should
understand why we would want to. I notice the native API is a double
underscore, so maybe that is a good sign that it is not correct to
expose this as is. Why not just have an API like this that is
exposed?

  /**
    * Returns the youngest revision number for path.
    * @since 1.6
    */
   public native long getYoungestRevisionNumber(String pathOrUrl);

Internally, this could call the native API and hide the other details.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org