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 01:59:15 CET