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

[Greg Hudson <gh...@MIT.EDU>]

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[kf...@collab.net]

Greg Hudson <gh...@MIT.EDU> writes:
> It doesn't seem like there will be much code to duplicate; just a call
> to svn_fs_deltify or whatever.

For those who are forking+execing, there is considerably more code to
deltify.

> I was thinking that svnserve in daemon mode would perform the commit,
> answer the caller, and then perform deltification--no need for a fork. 
> Your API doesn't allow for that.

Well, it does in a sense.  Just pass 'none' as the deltify_how
argument to the commit, then do whatever you want after the commit is
complete and the caller answered.

But I had forgotten that actually backgrounding might not be
necessary, and my API is not ideal for what you describe, especially
considering your point that mod_dav_svn might be able to do the same
thing:

> (It seems like mod_dav_svn should do the same thing if it can;
> otherwise, you risk subverting Apache's performance tuning mechanisms by
> creating background processes which can't be accounted for by Apache.)

Sleeping on it now, watch for more tomorrow.

Thanks for the feedback,
-Karl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Greg Hudson <gh...@MIT.EDU>]

On Wed, 2003-12-10 at 23:46, kfogel@collab.net wrote:
> 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.

It doesn't seem like there will be much code to duplicate; just a call
to svn_fs_deltify or whatever.

I was thinking that svnserve in daemon mode would perform the commit,
answer the caller, and then perform deltification--no need for a fork. 
Your API doesn't allow for that.

(It seems like mod_dav_svn should do the same thing if it can;
otherwise, you risk subverting Apache's performance tuning mechanisms by
creating background processes which can't be accounted for by Apache.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[kf...@collab.net]

Greg Hudson <gh...@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
worried.)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

["C. Michael Pilato" <cm...@collab.net>]

Greg Hudson <gh...@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.

I ... thought that's what Karl and Ben and Fitz and I agreed to
earlier today.  I think "in the background when possible" really means
"in the background when the RA layer says to do it that way, and if
possible".

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org