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

Re: "svn log" behavior and implementation

From: <kfogel_at_collab.net>
Date: 2001-10-23 17:11:04 CEST

Yoshiki Hayashi <yoshiki@xemacs.org> writes:
> I don't have anything against it but how about client pull
> interface? It will allow clients to decide not to get some
> properties or changed paths. I'm thinking about using this
> in my svnmirror script to get revision properties. Then it
> will be able to mirror Subversion repository with only
> Subversion protocol. What I'm saying is, I don't want to
> have changed_paths computed every time when I've already
> decided to ignore them. :-)
>
> The interface will be like:
>
> svn_error_t *(*get_rev_prop) (void *session_baton,
> svn_string_t **value,
> svn_string_t *name,
> svn_revnum_t revision)
>
> svn_error_t *(get_changed_paths) (void *session_baton,
> apr_array_header_t **changed_paths,
> svn_revnum_t revision)

Good point -- these might be good RA functions to have no matter what.

The reason I didn't want to depend on them for log is that then we use
a lot more network traffic per request. Log requests are pretty
frequent; although it's true that a client "might" want to get any
random revision property, in practice, they'll almost always be
getting these specific ones together: author, date, log message. In
order to have optimal response time, I think it makes sense to have
special support for this -- a custom request, and a custom report.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:45 2006

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