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

Re: permanent solution for deltification problem (issue #1601)

From: mark benedetto king <mbk_at_lowlatency.com>
Date: 2003-12-02 19:10:19 CET

On Tue, Dec 02, 2003 at 11:01:05AM -0600, kfogel@collab.net wrote:
>
> For Unix, I'm just going to make a fork() implementation after all.
> There's no reason to exec a separate process (and deal with the bother
> of locating the binary) if APR_HAVE_FORK. We'll just run the right
> code path directly, in a new child process; the parent process will
> continue on and most likely finish well before the child.

I had assumed that both the Windows and the Unix implementations would
use the same solution, namely that "svnadmin create" would place a
file containing the path to the svnadmin executable, and that the
svn_repos_fs_commit_txn() would simply use APR to spawn a background
process via that path.

I agree that your proposal is more efficient in the APR_HAS_FORK
case, but there are a few potential drawbacks that I'd like to point
out:

1.) Trivial duplication of code between svnadmin's subcommand_deltify().
    One might say that this is "tight coupling", and that we should
    keep the system "modular".
2.) Increased complexity of implementation.
3.) This is just FUD, but there may be some gotchas associated with
    forked BDB access that would not appear if the deltify happened in
    a brand-new process.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 2 19:10:54 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.