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-10-31 22:46:58 CET