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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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