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. :-)
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
>>> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-01 02:47:45 CET