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

Re: svn commit: r25670 - in trunk/subversion: include libsvn_subr libsvn_wc svn tests/cmdline/svntest

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-07-08 04:46:56 CEST

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

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.