Greg Hudson wrote:
>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.
>
>
I don't see any other posts from you on this thread, or indeed this month.
>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.
>
>
And in those environments, the repo administrator can tweak the
deltification configuration accordingly. Or the repos layer can decide
to do things differently based on access method -- but all of that
should be configurable.
>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.
>
>
But the deltification is a space optimisation. The commit has completed,
and that's all user has to know. There's no reason for the user to wait
on deltification.
>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.
>
>
Yes, but the difference in the constant factor between synchronous and
asynchronous deltification can be enormous, and at 30 seconds vs. 10
minutes, the "it's allways O(n)" argument won't make anyone happier.
> * 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.
>
>
I'm not looking at asymchronous deltification as a UI issue. Rather, I
believe that non-data-changing repository administration should be
independent of user actions, which means asynchronous. Whether this is
achieved via a cron job or a (fork+exec) is a secondary issue. However,
if we decided to remove unused log files by defailt, then we should also
turn on asynchronous deltification by default, because that's what the
vast majority of environments will want to use. Making things
configurable, even per access method, is fine, as far as I'm concerned.
Using different criteria to choose the default behaviour is not.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 2 20:13:26 2003