On Tue, 2003-12-02 at 12:01, kfogel@collab.net wrote:
> For Unix, I'm just going to make a fork() implementation after all.
I feel like you guys talk to me about this, and I discuss some
constraints, and you agree with them, and then you go talk to other
people and forget about the conversations you had with me, and we have
to keep going around in circles.
It is not okay for "svn ci file://..." to exit while it is continuing to
access the database in the background, at least not by default. In that
case, deltification must be synchronous if it happens at all. This is
because of a variety of corner cases:
* In some environments, user processes may be killed after logout.
* In some environments, user processes may lose access to some
filesystems after logout.
* People may write scripts which mount a filesystem, perform svn
operations on a repository within the filesystem, and then
unmount the filesystem.
svn is a tool, and tools must obey certain constraints to be
well-behaved, and one of those constraints is that you don't exit before
you're done.
A similar argument applies to ra_svn in tunnel mode.
I think we may have been looking at this issue from the wrong angle:
* If the problem is that commits of large files take too long, then we
should get over it; we will never be able to commit an N-byte file in
less than O(n) time because of the way working copies work.
* If the problem is that there is a long deltification delay at the
end of a commit, with no user feedback, then we should either try to
make deltification happen on a per-file basis during the commit, or add
some feedback to the deltification process.
* If the problem is that HTTP clients time out during the
deltification delay, then we should turn off HTTP client timeouts by
default, as we should have done years ago.
I do not object to an option to make deltification asynchronous, as long
as it is not turned on by default. But I don't think it's really a
solution; it's more of a workaround.
---------------------------------------------------------------------
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:31:35 2003