It could expose more if someone demonstrates a *need*, and then somebody does
the work. :)
-Hyrum (the JavaHL code monkey these days)
Mark Phippard wrote:
> JavaHL only exposes the libsvn_client layer. It could expose more if
> someone does the work, but doesn't currently.
>
> Sent from my iPhone
>
> On Oct 31, 2008, at 8:59 PM, "Ben Collins-Sussman"
> <sussman_at_red-bean.com> wrote:
>
>> Wha? No replay API in JavaHL? And the swig-java bindings are that
>> dead?
>>
>> On Fri, Oct 31, 2008 at 4:53 PM, Mark Phippard <markphip_at_gmail.com>
>> wrote:
>>> It is not available in Java unless SVNKit supports it. Which they
>>> probably
>>> do.
>>>
>>> Sent from my iPhone
>>>
>>> On Oct 31, 2008, at 5:46 PM, "Ben Collins-Sussman"
>>> <sussman_at_red-bean.com>
>>> wrote:
>>>
>>>> On Fri, Oct 31, 2008 at 2:12 AM, Thomas Mauch <thomas.mauch_at_gmx.net>
>>>> wrote:
>>>>>
>>>>> I sent this email four days ago to the users mailing list, but got no
>>>>> feedback.
>>>>> I therefore sent it now to the dev mailing list as well. As
>>>>> mentioned, I
>>>>> see
>>>>> its content related to issue 898 which is marked as 1.6-consider.
>>>>> Can any
>>>>> body tell what the current state is?
>>>>>
>>>>> Thanks,
>>>>> Thomas
>>>>> ----------------------------------------------------------------
>>>>>
>>>>> http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=83682
>>>>>
>>>>> I was experimenting with svn log to trace the actions applied to the
>>>>> Subversion repository. The basic idea was that it should be
>>>>> possible to
>>>>> detect what happened to the files at a high level by just looking
>>>>> at the
>>>>> svn
>>>>> log output. And on the first look it seems that svn log has been
>>>>> written
>>>>> with this idea.
>>>>>
>>>>> However there are a few subtleties which are not fully covered. So
>>>>> I am
>>>>> not
>>>>> able to distinguish between the two different actions
>>>>> 1) copy file f1 to f2, commit
>>>>> 2) copy file f1 to f2, modify file f2, commit
>>>>> As a consequence if I see an Add action in the svn log output, I
>>>>> have to
>>>>> access the repository and make a diff between file1 and file2 to
>>>>> detect
>>>>> whether it has just been copied or it has also been modified.
>>>>>
>>>>> The same is true for renaming files. When searching around, I found
>>>>> the
>>>>> rename cases mentioned in presentation "Subversion 1.4 true renames
>>>>> problems" appended to issue 898. However I found no further
>>>>> information
>>>>> how
>>>>> this shortcomings of svn log should be addressed by issue 898. Are
>>>>> there
>>>>> further information available?
>>>>>
>>>>> IMHO it should be the clear objective that the output of svn log
>>>>> provides
>>>>> you with all the information you need to trace actions on files
>>>>> without
>>>>> having to access the repository. And this should hold for property
>>>>> changes
>>>>> as well, so you could easily distinguish the cases 1 and 2 from
>>>>> 3) copy file f1 to f2, change property of file f2, commit
>>>>>
>>>>> What do you think?
>>>>
>>>> I think you're confusing 'svn log' (which is meant for human
>>>> readability), with the svn_ra_replay() API, which is meant for
>>>> programmatic access. The 'svn log' command is not a perfect record
>>>> (as you've discovered) of what has changed, as it has some
>>>> ambiguities. That doesn't trouble the svn developer community,
>>>> however, since we've always considered API access to be the 'correct'
>>>> way to understand history, rather that relying on parsing the output
>>>> of the svn commandline client (whose output can change over time,
>>>> etc.)
>>>>
>>>> The svn_ra_replay() API is what you're looking for; it actually
>>>> describes repository changes using the 'editor' vtable the same way
>>>> all other revisions are described. The API is available in java,
>>>> perl, python, C, whatever you want. Go for the real stuff. :-)
Received on 2008-11-01 14:45:50 CET