[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-06-08 14:29:53 CEST

On 6/7/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 6/7/07, Mark Phippard <markphip@gmail.com> wrote:
> > I was with you until the last part. I think the "built-in" simple
> > acceptance callbacks shiould be more intelligent than operating on the
> > entire file. I think they ought to still merge the non-conflicting
> > hunks and only use this acceptance hint on the hunks that are in
> > conflict.
> I agree, I was imagining that the non-conflicting hunks still get
> merged before the callback is ever invoked. In other words: do our
> existing 3-way merge exactly as we do today. If the merge results in
> a conflicted file (i.e. some hunks aren't mergeable), *then* we check
> for a callback to invoke. We pass filehandles to the callback for the
> fulltexts, as well as a handle to the 'mostly merged' working file.
> The only thing I don't understand is what you mean by using a 'hint'
> on the conflicting chunks. In the --accept callback implementation,
> you imagine some value meaning "use my file", anothehr value that
> means "use their file", and a third value that means "use the
> mostly-merged working file, and favor conflicting hunks in one
> direction?"

I was imagining the merge process could know that you said
--accept=mine and when it encounters a conflicting hunk it could just
apply the appropriate hunk and discard the other. No conflict would
need to be generated in this case.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 8 14:30:03 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.