-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> My API would look like this
>>
>> /**
>> * Returns the revision number as represented by @revision.
>> * To ensure consistency of HEAD across multiple operations,
>> * one can pass valid @youngestRevision so that it would return
>> * @youngestRevision. @youngestRevision can be null if one
>> * does not want ensure the consistent HEAD.
>> * If @youngestRevision is Revision.SVN_INVALID_REVNUM and
>> * revision's kind is HEAD we set @youngestRevision with
>> * return value of this function.
>> * @since 1.6
>> */
>> public native long getRevisionNumber(
>> Revision.Number youngestRevision,
>> String pathOrUrl,
>> Revision revision);
>>
>>
>> Attaching the patch to create object Revison.Number.Number(-1).
>>
>> Would like to what others think about this.
>>
>> With regards
>> Kamesh Jayachandran
>>
>>
>
> So you are saying you want to add a new method to JavaHL that gets the
> youngest revision number for a WC or URL? And to do that you need to
> be able to pass a -1 into the native function? Is there some reason
Yes.
> 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.
Thanks
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH6maD3WHvyO0YTCwRAor6AJsEzfOlE5yk/EuE+irTnnHZYefhNQCfW90t
3JSlkRGiuC1Ok96fWXWb/sc=
=82ju
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-26 16:07:26 CET