[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: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-07-18 02:26:25 CEST

Aw, crud, you guys are right. I need to fix that. When perforce
prompts you whether you want to "choose mine or theirs", it's
referring to conflicting hunks, not the entire file. Gah.

Thanks for pointing this out.

On 7/17/07, Karl Fogel <kfogel@red-bean.com> wrote:
> 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?" :-)
> -Karl

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:25:34 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.