On 7/7/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 7/6/07, David Glasser <glasser@mit.edu> wrote:
> > Also, hmm. In svn_wc_conflict_description_t I'm not really
> > comfortable with the way that the "real" version the file (the one
> > without any suffixes, the one that (a)ccept accepts, the only one
> > that's worth editing) is sometimes user_file and sometimes
> > merged_file, depending on whether or not the file is binary. I see
> > why you did that but I'm wondering if there's a better way (like
> > making both user_file and merged_file the same file? or making
> > user_file be the NULL one for binary files?).
>
> I think you've got it backwards. Here's how I see things.
>
> For a text file, we get 4 files: base, mine, theirs, merged (with
> conflict markers.) The one that gets edited by (e)dit or (l)aunch is
> the 'merged' version. The user can select any of the 4 files as the
> 'final file to use" , and signals this choice by the callback
> returning one of the specific "result_choose_*" values.
>
> For a binary file, we get 3 files: base, mine, theirs. There is no
> merged file. I don't think (e)dit should function as an option,
> therefore. If a third-party tool (via (l)aunch) wants to merge the 3
> existing files into a final 'merged' file, and overwrite the working
> file with a merged file, that's fine, and probably a recommended best
> practice. I would expect the callback to then return
> 'result_resolved' (which means, "I've taken care of the conflict,
> don't worry about it.")
>
> Does my vision make sense?
Yeah, it does.
Actually, I think I now understand why I was confused above. Without
the conflict handler, the result of "svn up" on a conflict is four
files: foo, foo.r1, foo.r2, and foo.mine. It's the "merged" one that
has the actual file name "foo", and so in a way the merged file is
blessed by the client as the "canonical" version of the file. For
binary files, it's the "mine" version that is "canonical".
I was thinking that this concept of "canonical" file is important for
the conflict handler to be aware of, and the fact that sometimes it
is merged_file and sometimes user_file seemed wrong to me. However,
on further thought I'm not sure that this is important, especially
since I now realize that the creation of these files only happens
*after* the resolution phase if the user (p)ostpones, and during the
phase it's all temporary files. The "canonical" file is still
slightly important (it looks like it's the one that's used if you
return result_resolved), but the rule of "for textual merges, the
canonical file is merged_file if it's non-NULL and user_file
otherwise" seems fine to me now.
--dave
--
David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 8 07:24:46 2007