Separate options to enable text deltas and property changes for 'replay' operation

[Dmitry Batrak <ba...@gmail.com>]

Hi,

I'm a developer of SVN revision graph plugin for IntelliJ IDEA
(http://code.google.com/p/svn-rev-graph/).
The graph, that the plugin builds, includes merge information that is
obtained from 'log -g' output.

I'm looking at implementing a cache of history data to avoid a large
number of repository calls that is
required currently to collect all the required information. I know
this has been implemented already, e.g. in
TortoiseSVN or Subclipse plugin, except that those implementations
don't include merge information (although
Subclipse has related functionality, it's quite limited).

The most convenient API call to fetch the required data I've found is
'replay_range', as it returns both
'structural' changes and properties changes. But property changes can
only be received together with text
deltas, which in this case are not needed. Adding an option to send
only property changes would save
some time and traffic. Would it be possible to extend replay
functionality in this way? Or maybe you
could suggest another way to get the same information from remote repository?

Best regards,
Dmitry Batrak

Re: Separate options to enable text deltas and property changes for 'replay' operation

[Daniel Shahaf <da...@elego.de>]

Dmitry Batrak wrote on Fri, Apr 06, 2012 at 00:30:06 +0400:
> The most convenient API call to fetch the required data I've found is
> 'replay_range', as it returns both 'structural' changes and properties
> changes. But property changes can only be received together with text
> deltas, which in this case are not needed. Adding an option to send
> only property changes would save some time and traffic. Would it be
> possible to extend replay functionality in this way? Or maybe you
> could suggest another way to get the same information from remote
> repository?

Just wanted to say: if you haven't found another API (in svn_ra.h) that
solves your problem, I'd be happy to consider an extension of the API
that omits only file contents.  (Please review svn_editor.h before
designing such an extension.)

Let me warn you, though: it'll be a moderately large patch, since
extending the on-the-wire API involves patching all 3 network servers
and all 4 network clients (libsvn_ra_*, svnserve, mod_dav_svn).