You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2008/03/26 14:34:22 UTC
[PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Hi All,
I am working on exposing 'svn_client__get_revision_number' in JavaHL.
I want a equivalent of youngest_rev(in/out param in
svn_client__get_revision_number method).
Unfortunately our JavaHl does not allow revision numbers to be '-1'.
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
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> I can use null, but when I want to use an object as In/Out param it
>> won't be useful. I need Revison.Number.Number(-1) to know that as an Out
>> Param and Revison.Number.Number(ANY_VALID_NUMBER) as an In param.
>
> Do we use in/out params other places in JavaHL? If we need to return
> multiple values, it would seem more Java-y to create a new wrapper class
> and return that...
Not sure. I already have this implemented in my WC. Anyways info() seem
to help.
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH67iS3WHvyO0YTCwRAtRGAJ4tey3Lh5IhEnl8xm8EpDJKELL2HgCgsoFm
h0YBdkigrzEQop5lfpEQhfk=
=1Rw9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Kamesh Jayachandran wrote:
>
>
> David Glasser wrote:
>> On Wed, Mar 26, 2008 at 7:34 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>>> Hi All,
>>>
>>> I am working on exposing 'svn_client__get_revision_number' in JavaHL.
>>>
>>> I want a equivalent of youngest_rev(in/out param in
>>> svn_client__get_revision_number method).
>>>
>>> Unfortunately our JavaHl does not allow revision numbers to be '-1'.
>> I would think that your change would be confusing, since people
>> familiar with the Subversion API would expect "-1" to be
>> SVN_INVALID_REVNUM.
>
>> Does the JavaHL API really not use an equivalent of SVN_INVALID_REVNUM anywhere?
>
>> Could you just use null?
>
>
> I can use null, but when I want to use an object as In/Out param it
> won't be useful. I need Revison.Number.Number(-1) to know that as an Out
> Param and Revison.Number.Number(ANY_VALID_NUMBER) as an In param.
Do we use in/out params other places in JavaHL? If we need to return
multiple values, it would seem more Java-y to create a new wrapper class
and return that...
-Hyrum
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Glasser wrote:
> On Thu, Mar 27, 2008 at 2:09 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>>
>> David Glasser wrote:
>> > On Wed, Mar 26, 2008 at 7:34 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>> >> Hi All,
>> >>
>> >> I am working on exposing 'svn_client__get_revision_number' in JavaHL.
>> >>
>> >> I want a equivalent of youngest_rev(in/out param in
>> >> svn_client__get_revision_number method).
>> >>
>> >> Unfortunately our JavaHl does not allow revision numbers to be '-1'.
>> >
>> > I would think that your change would be confusing, since people
>> > familiar with the Subversion API would expect "-1" to be
>> > SVN_INVALID_REVNUM.
>> >
>> > Does the JavaHL API really not use an equivalent of SVN_INVALID_REVNUM anywhere?
>> >
>> > Could you just use null?
>>
>>
>> I can use null, but when I want to use an object as In/Out param it
>> won't be useful. I need Revison.Number.Number(-1) to know that as an Out
>> Param and Revison.Number.Number(ANY_VALID_NUMBER) as an In param.
>
> Ugh, Revision.Number is a mutable type? That strikes me as a poor choice...
>
SVNClient.info2() saves me from getting the desired information so no
need of new JAVAHL API.
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH68Vt3WHvyO0YTCwRArmwAJ0R8OLuVOmd3KmqbJgHklItv3iWWgCdGnRO
aULA8Gp86tb89gWzG5Lyo3s=
=L4Zx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by David Glasser <gl...@davidglasser.net>.
On Thu, Mar 27, 2008 at 2:09 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
>
> David Glasser wrote:
> > On Wed, Mar 26, 2008 at 7:34 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> >> Hi All,
> >>
> >> I am working on exposing 'svn_client__get_revision_number' in JavaHL.
> >>
> >> I want a equivalent of youngest_rev(in/out param in
> >> svn_client__get_revision_number method).
> >>
> >> Unfortunately our JavaHl does not allow revision numbers to be '-1'.
> >
> > I would think that your change would be confusing, since people
> > familiar with the Subversion API would expect "-1" to be
> > SVN_INVALID_REVNUM.
> >
> > Does the JavaHL API really not use an equivalent of SVN_INVALID_REVNUM anywhere?
> >
> > Could you just use null?
>
>
> I can use null, but when I want to use an object as In/Out param it
> won't be useful. I need Revison.Number.Number(-1) to know that as an Out
> Param and Revison.Number.Number(ANY_VALID_NUMBER) as an In param.
Ugh, Revision.Number is a mutable type? That strikes me as a poor choice...
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Glasser wrote:
> On Wed, Mar 26, 2008 at 7:34 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>> Hi All,
>>
>> I am working on exposing 'svn_client__get_revision_number' in JavaHL.
>>
>> I want a equivalent of youngest_rev(in/out param in
>> svn_client__get_revision_number method).
>>
>> Unfortunately our JavaHl does not allow revision numbers to be '-1'.
>
> I would think that your change would be confusing, since people
> familiar with the Subversion API would expect "-1" to be
> SVN_INVALID_REVNUM.
>
> Does the JavaHL API really not use an equivalent of SVN_INVALID_REVNUM anywhere?
>
> Could you just use null?
I can use null, but when I want to use an object as In/Out param it
won't be useful. I need Revison.Number.Number(-1) to know that as an Out
Param and Revison.Number.Number(ANY_VALID_NUMBER) as an In param.
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH62Q03WHvyO0YTCwRAp3fAKCuswGEaZhObpIYuMG08vl+aiVd+QCdEzb4
JcqiIoorqq4mQqvqHsRG3ek=
=ySYI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by David Glasser <gl...@davidglasser.net>.
On Wed, Mar 26, 2008 at 7:34 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> Hi All,
>
> I am working on exposing 'svn_client__get_revision_number' in JavaHL.
>
> I want a equivalent of youngest_rev(in/out param in
> svn_client__get_revision_number method).
>
> Unfortunately our JavaHl does not allow revision numbers to be '-1'.
I would think that your change would be confusing, since people
familiar with the Subversion API would expect "-1" to be
SVN_INVALID_REVNUM.
Does the JavaHL API really not use an equivalent of SVN_INVALID_REVNUM anywhere?
Could you just use null?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Mark,
>> 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.
The indexing module that I work on uses JavaHL.
On regular intervals my indexing module is run to do indexing of recent
commits since last index time(Unfortunately we don't track the last indexed rev)
My indexing module runs 'log' between r{LASTUPDATETIME}:HEAD.
Consider LASTINDEXEDTIME='2007-12-25' and no commits in my repository
since then. My last indexed rev and HEAD is r50.
Now my log give a log entry for r50.
How much ever time you run this log operation it would give r50.
Consider the case when I run this indexing code across 1500 repositories
every 1 hour of which most the repositories did not have any commit.
I end up indexing atleast one revision of each repository so frequently.
Assuming my indexing is costly, I want to avoid that if,
LastIndexedRev=SVNClientObj.getRevisionNumber(null, url_to_my_repo, Revision.DateSpec(MyLastIndexTime))
HeadRev=SVNClientObj.getRevisionNumber(null, url_to_my_repo, Revision.HEAD)
If HeadRev == LastIndexedRev:
Skipe indexing.
Else:
Index applicable revisions since LastIndexedRev+1
In my above usecase I do not need YoungestRev for the sake of completeness I would like to support that.
>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.
As mentioned above I need date to rev possibly for others 'COMMITTED' to rev etc.
With regards
Kamesh Jayachandran
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Mar 26, 2008 at 2:57 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> Kamesh Jayachandran wrote:
> >> Mark Phippard wrote:
> >>> 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.
> >
> >> It would still need to call a public libsvn_client API, since the C++
> >> layer of the JavaHL bindings only has access to public APIs.
> >
> > If I understand correctly we can make use functions with '__' in their name from
> > other svn libraries from JavaHL as we already use such intra library functions
> > from libsvn_fs_util in libsvn_fs_(fs|base).
>
> Well, we don't currently do so anywhere in the C++ side of JavaHL, and
> I'm just a little leery of getting into that habit. I see the JavaHL
> bindings as just another consumer of the client API, which just happens
> to live in our repo; I don't see why it should get special privileges.
> This is completely orthogonal to the purpose of libsvn_fs_util.
I do not believe this will work anyway. On Windows, only the public
API is exported by the DLL interface, so I do not see how the JavaHL
code could access the private symbols.
--
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
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Well, that's fine, if there's a need for it. I'm against promoting an
> API for the sake of promoting an API, though. Looking back at your
> proposed JavaHL API, is there a reason why you need to add an API to
> JavaHL? Why can't you use info() to get the revision numbers you are
> interested in, and do the youngest v. HEAD comparisons in a wrapper?
>
Yes info() helps!. Thanks.
> It's possible that I don't fully grasp what you are trying to do here.
I am trying to convert svn_opt_revision_t to svn_revnum_t in JavaHL.
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH67fF3WHvyO0YTCwRAkqvAJ49iBrqcICR2/32fDc3S3c5EHr4LACfYI6M
v5OgMcil9v8msEAf9VgS7jA=
=pvjm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Kamesh Jayachandran wrote:
>> Well, we don't currently do so anywhere in the C++ side of JavaHL, and
>> I'm just a little leery of getting into that habit. I see the JavaHL
>> bindings as just another consumer of the client API, which just happens
>> to live in our repo; I don't see why it should get special privileges.
>> This is completely orthogonal to the purpose of libsvn_fs_util.
>
>
> Well, if it is the case why not promote
> 'svn_client__get_revision_number' to be a public API by renaming it and
> keeping the symbol in subversion/include/svn_client.h?
Well, that's fine, if there's a need for it. I'm against promoting an
API for the sake of promoting an API, though. Looking back at your
proposed JavaHL API, is there a reason why you need to add an API to
JavaHL? Why can't you use info() to get the revision numbers you are
interested in, and do the youngest v. HEAD comparisons in a wrapper?
It's possible that I don't fully grasp what you are trying to do here.
-Hyrum
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>
> Well, we don't currently do so anywhere in the C++ side of JavaHL, and
> I'm just a little leery of getting into that habit. I see the JavaHL
> bindings as just another consumer of the client API, which just happens
> to live in our repo; I don't see why it should get special privileges.
> This is completely orthogonal to the purpose of libsvn_fs_util.
>
Well, if it is the case why not promote
'svn_client__get_revision_number' to be a public API by renaming it and
keeping the symbol in subversion/include/svn_client.h?
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH6zx03WHvyO0YTCwRAvCBAJ9psfYj/ZnvOSOBbZQGROzyWN6EtACeIsIe
RHMob4WhN2yowf+xaXkfkKw=
=IXDv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Kamesh Jayachandran wrote:
>> Mark Phippard wrote:
>>> 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.
>
>> It would still need to call a public libsvn_client API, since the C++
>> layer of the JavaHL bindings only has access to public APIs.
>
> If I understand correctly we can make use functions with '__' in their name from
> other svn libraries from JavaHL as we already use such intra library functions
> from libsvn_fs_util in libsvn_fs_(fs|base).
Well, we don't currently do so anywhere in the C++ side of JavaHL, and
I'm just a little leery of getting into that habit. I see the JavaHL
bindings as just another consumer of the client API, which just happens
to live in our repo; I don't see why it should get special privileges.
This is completely orthogonal to the purpose of libsvn_fs_util.
-Hyrum
RE: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Kamesh Jayachandran <ka...@collab.net>.
>Mark Phippard wrote:
>> 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.
>It would still need to call a public libsvn_client API, since the C++
>layer of the JavaHL bindings only has access to public APIs.
If I understand correctly we can make use functions with '__' in their name from
other svn libraries from JavaHL as we already use such intra library functions
from libsvn_fs_util in libsvn_fs_(fs|base).
With regards
Kamesh Jayachandran
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Mark Phippard wrote:
> 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.
It would still need to call a public libsvn_client API, since the C++
layer of the JavaHL bindings only has access to public APIs.
-Hyrum
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Mar 26, 2008 at 11:06 AM, Kamesh Jayachandran <ka...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Mar 26, 2008 at 10:34 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> I am working on exposing 'svn_client__get_revision_number' in JavaHL.
>
> I want a equivalent of youngest_rev(in/out param in
> svn_client__get_revision_number method).
>
> Unfortunately our JavaHl does not allow revision numbers to be '-1'.
>
> 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
>
> [[[
> JavaHL's Revision.Number.Number(long) should accept -1, to
> implement a behaviour that can set 'Revision.Number' object
> with some valid revision if it is '-1'.
>
> * subversion/bindings/javahl/src/org/tigris/subversion/javahl/Revision.java
> (Revision.Number.Number): Accept -1 as special revision number.
> ]]]
>
> inside svn_client__get_revision_number revision->kind=5
> Index: subversion/bindings/javahl/src/org/tigris/subversion/javahl/Revision.java
> ===================================================================
> --- subversion/bindings/javahl/src/org/tigris/subversion/javahl/Revision.java (revision 30056)
> +++ subversion/bindings/javahl/src/org/tigris/subversion/javahl/Revision.java (working copy)
> @@ -209,7 +209,7 @@
> public Number(long number)
> {
> super(Kind.number, true);
> - if (number < 0)
> + if (number < SVN_INVALID_REVNUM)
> throw new IllegalArgumentException
> ("Invalid (negative) revision number: " + number);
> revNumber = number;
>
>
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
this cannot just be hidden in the method interface? I guess I just do
not understand what this new method does or when someone would call
it. The JavaDoc is not really clear to me.
--
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