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

Re: svn commit: rev 7974 - in branches/issue-1601-dev/subversion: include libsvn_ra_local libsvn_repos mod_dav_svn svnserve tests/libsvn_repos

From: <kfogel_at_collab.net>
Date: 2003-12-11 05:46:17 CET

Greg Hudson <ghudson@MIT.EDU> writes:
> On Wed, 2003-12-10 at 16:38, kfogel@tigris.org wrote:
> > Start work on issue #1601: to do deltification unconditionally as part
> > of the commit, but in the background when possible, so the user
> > doesn't wait.
> This approach seems baroque. Can't we just make the RA back end
> responsible for performing deltification after a comment? The back end
> can do so synchronously or asynchronously as appropriate.

Er, hmm. I'm not sure how to answer that. The point of this approach
is to achieve exactly the goal you state above. "Baroque" is a matter
of taste, I guess.

Here is the reasoning:

Each RA layer is going to want to decide when/how to do deltification.
In order to avoid the various RA layers duplicating the same code, we
naturally want to factorize the deltification possibilities. What's
the right place to do that? Oh ho, look, libsvn_repos is the right
place. And if we make the deltification decision part of the commit
API, then no RA implementor can accidentally forget to make the
decision. One may consciously decide not to deltify, and pass the
appropriate flag, but one may not simply pass no flag.

The approach I am coding does all this, leaving the decision itself to
the RA layer, as simply as I could figure out how.

(Or was your question based on the one-paragraph summary from the log
message that you quote above? In that case, the answer is: look at
the full log message, and the change itself, and see if you're still


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 11 06:34:20 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.