On Tue, 2005-05-17 at 21:36 +0200, Branko Èibej wrote:
> According to Karl's proposal, we'd have a special RA function to get the
> log template... then later on, we'd find something else for the client
> to pull from the server, and add a second RA function... and a third...
> That's nuts; even more so because it costs almost nothing to have the
> function take an additional parameter that identifies the data to be sent.
But log templates require a specific kind of input (the directories to
be committed) which makes no sense for other kinds of server-to-client
configuration under discussion.
> Just for the record. IMHO we don't need it for log templates, either. It
> may be sexy to have them generated based on the set of paths to be
> committed, but that /is/ overkill IMNSHO.
I don't think it's at all overkill for situations like the ASF
repository. If a single repository-wide log template were good enough
for the vast majority of cases, I don't think we'd have seen the
per-directory functionality in CVS.
> Besides, suddenly you'd have
> an extra trip over the network regardless of whether you use log
> templates or not, and I'm very close to vetoing the proposal for that
> reason alone.
That would be ridiculous. A single network turnaround is generally a
tiny fraction of a second; in the extreme cases where it's much longer
than that, the user generally expects things to be slow. We should not
be worrying about the number of turnarounds per large-grain operation
like commit.
Over HTTP, I believe we currently have a network turnaround *per
committed file*, and yet performance is considered acceptable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 17 22:36:05 2005