On Fri, 08 Jun 2007, C. Michael Pilato wrote:
> Ben Collins-Sussman wrote:
> > One of the next things on my plate is to give users the option to
> > resolve conflicts interactively. That is, rather than
> > update/switch/merge just marking files as 'conflicted' and then
> > letting the user deal with the conflicts later on, the whole process
> > can optionally pause on a conflict and have the user interactively
> > resolve the problem on the spot.
>
> Great idea. One concern: if I recall correctly, we had to remove the
> streaminess from the merge operation as run under ra-dav because the time it
> takes to deal with certain merge situations was backing up the network pipe
> until Apache killed it. Remember that? The primary merge operation's
> REPORT response is squirreled away to a tempfile on disk now, then read back
> and played through the editor interface as if it was "live".
>
> Anyway, if we add interactivity of this sort (which means "potentially
> infinite pausing") I suspect we'll run into the same situations for even
> common update operations. The solution to this might mean exposing the
> to-be-streamy-or-not-to-be-streamy flag to callers of the RA layers (even
> though Apache is the only server that has the issue, svnserve doens't seem to).
While the conflict resolution callback is invoked after a merge to a
path results in a conflict, the editor drive could still be
in-progress, meaning that network I/O could be blocked on conflict
resolution.
Because update is doing a tree edit, we can't just notice paths in
conflict and perform the resolution at the end, since previous
(unresolved) tree conflicts might clash with subsequent work by the
delta editor.
- application/pgp-signature attachment: stored
Received on Fri Jun 8 22:03:56 2007