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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 8 04:46:46 2007