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

Re: svn commit: r1242958 - /subversion/trunk/subversion/libsvn_repos/log.c

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 17 Feb 2012 23:13:39 +0000

Hyrum K Wright <hyrum.wright_at_wandisco.com> writes:

> On Fri, Feb 10, 2012 at 4:24 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>>> -----Original Message-----
>>> From: hwright_at_apache.org [mailto:hwright_at_apache.org]
>>> Sent: vrijdag 10 februari 2012 23:11
>>> To: commits_at_subversion.apache.org
>>> Subject: svn commit: r1242958 -
>>> /subversion/trunk/subversion/libsvn_repos/log.c
>>> Author: hwright
>>> Date: Fri Feb 10 22:10:34 2012
>>> New Revision: 1242958
>>> URL: http://svn.apache.org/viewvc?rev=1242958&view=rev
>>> Log:
>>> Older (pre-1.6) revision files don't contain the information to fully populate
>>> the changed_path hash for 'log -v' and 'log --xml'.  If we encounter such a
>>> condition, fetch the kind manually.
>> Why do we add this now?
>> We started sending the information 'when available' with 1.6, and I
>> think we didn't retrieve the data for performance reasons. Did
>> something change?
> User request (through private channels). They were parsing the output
> of 'log --xml' which shows a blank 'kind' attribute against these old
> revisions. Fetching the kind as part of the log is much easier, both
> for the user and for performance, than individually running 'svn info'
> on each node.
> Arguably, they could cache this information somewhere client-side,
> since the historic information isn't going to change. But that's what
> the VCS is for in the first place.
>> This might be quite a performance regression for 'svnadmin upgrade'-d
>> servers that were from <=1.5 before the last dump-load and it won't
>> make the information magically available on clients, because there is
>> no requirement to upgrade the server.
> Possibly, but I think we already say that running 'log -v' may take a
> while longer than "normal" log. I also think the number of such
> instances likely to be encountered in the wild are few, and the
> benefits to those that do want this information outweigh the costs.

So this code didn't work for deleted nodes, it's necessary to track back
to a revision in which the node exists. I've fixed it with r1245800 but
that probably makes it now even more expensive.

uberSVN: Apache Subversion Made Easy
Received on 2012-02-18 00:14:16 CET

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