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-10-31 22:53:59 CET