Greg Hudson <ghudson@MIT.EDU> writes:
> 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.
Hmm. I never intentionally ignore your mails. In this case, though,
I have no memory of agreeing with what you say below. Maybe I
misunderstood what you were saying, and agreed with the
misunderstanding instead of with what you actually meant.
Anyway, sorry if it seems like I'm reneging, but I do think
deltification has to be asynchronous, because the user delay is too
noticeable. It doesn't matter that deltification is technically O(N),
when the constant factor is so high.
> 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.
These environments seem quite rare. We'll have an option for either
making deltification synchronous, or turning it off, but I think it's
still up to the administrator to realize that they've got an unusual
situation and set that option appropriately. Our docs can mention
this, but we shouldn't penalize everyone for the sake of the few.
Or am I wrong about how rare these are? The only way to estimate the
danger here is to know how often these situations occur in real life.
After all, in some environments NULL != 0, but we don't lie awake at
night worrying about it.
> A similar argument applies to ra_svn in tunnel mode.
Sure.
> 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.
Mmm, I see what you're saying, but I don't think we're approaching it
from the wrong angle. The first and third bullet points were not the
motivators behind this issue -- it's only the second.
The lack of user feedback is only part of the problem. Even if the
client printed out "Deltifying..." or whatever, the delay itself would
still be there.
And, Mike just pointed out (verbally) that doing deltification
per-file during the commit is not a good option. If the commit is
aborted, then all of those deltifications have to be undone, because
the things they're deltifying *against* will not exist after the txn
is removed. Bleargh. No, we should deltify only after the new
revision is safely esconced.
> 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.
Well, I have no compelling proof one way or the other; the difference
between a solution and a workaround is a matter of taste. All I can
say is that I think this falls into the category of a "bug" with a
"solution" available.
If the technical dangers are greater than I'm aware of, that would
change my mind. But the situations you describe above don't seem like
they should affect our design...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 3 00:51:30 2003