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

Re: RFC: interactive conflict resoution callback

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-06-08 22:03:47 CEST

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

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

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.