[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

AW: Re: Traceability of svn log

From: Thomas Mauch <thomas.mauch_at_gmx.net>
Date: Wed, 5 Nov 2008 08:37:09 +0100

Thanks for your answers.

I agree with you that clear APIs are most important.
However I think that it would nevertheless be helpful if the
end user also has all the information available he would like
to have. So why should the svn log output does not contain al
information? May be there is a chance to change this in the future.

At least the XML output is not really thought for human readability
but for analysis with programs so accurate information is needed.
In the meantime, if I really need the full history, I would look
for suitable Java API but there seems to be some confusion whether
this API is included or not. Can you point me to the right class
in SVNKit?

Thanks,
Thomas

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.)

-----Ursprüngliche Nachricht-----
Von: Hyrum K. Wright [mailto:hyrum_wright_at_mail.utexas.edu]
Gesendet: Samstag, 1. November 2008 14:46
An: Mark Phippard
Cc: Ben Collins-Sussman; Thomas Mauch; dev_at_subversion.tigris.org
Betreff: *** GMX Spamverdacht *** Re: Traceability of svn log

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. :-)

---------------------------------------------------------------------
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-05 10:18:42 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.