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

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
Received on 2008-03-26 18:48:25 CET