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

Re: svn_wc_conflict_result_choose_repos found dangerous?

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-07-18 02:06:01 CEST

Daniel Rall <dlr@collab.net> writes:
> WRT issue #2830, "Improve handling for conflicts encountered during a
> merge": http://subversion.tigris.org/issues/show_bug.cgi?id=2830
> On IRC yesterday, we were discussing some of the new "automated
> conflict resolution" result codes (from svn_wc_conflict_result_t)
> available to the excellent new conflict resolution callback
> (svn_wc_conflict_resolver_func_t) when the conflicted path is a file,
> and its merge sources share a common ancestry.
> Specifically, we were talking about the potential dangers of the
> svn_wc_conflict_result_choose_repos result code, which causes the
> repository version of the file to be copied over the top of the user's
> working version, ***without preserving any of the user's unconflicting
> local mods***. This last part is going to be a gotcha for users, who
> are going to expect only conflicting portions of the merge to be
> discarded in favor of the repository's version, and are going to be
> pissed when their local cahnges are discarded. Other VC systems I've
> looked at work by operating on a chunk-by-chunk basis, rather than on
> a whole file.
> On further reflection I think our concerns also apply somewhat to the
> other result codes (e.g. choosing svn_wc_conflict_result_choose_user
> will discard unconflicting hunks frmo the merge).
> Thoughts?

+1 on doing what the other VC systems do. There's got to be a
way to make our diff3 code favor the repository changes (or the user's
changes, whatever) *only* where there's a conflict. "Favoring"
shouldn't even be a question for the non-conflicting regions;
certainly it at least shouldn't be the default behavior there.

I use "there's go to be a way to make our diff3 code to XYZ" to mean
"there's go to be a way to make our diff3 code do XYZ... right?" :-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 18 02:05:09 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.