[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-07-18 18:29:27 CEST

On 7/18/07, David Glasser <glasser@mit.edu> wrote:
> On 7/18/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> > Hm, allow me to reverse my position here; a few coworkers just
> > lectured me that the idea of "select-theirs-hunk-wise" is utterly
> > insane, because it's essentially unpredictable. Some of your edits
> > are conflicting, some are not; why would a user select an option that
> > means "throw away some of my edits, but not others", when he has no
> > real idea which edits are about to be tossed? The result has a
> > non-deterministic feel to it. By selecting the entire file from the
> > repository, at least you're getting a known good state -- something
> > syntactically and semantically reasonable -- and you know exactly
> > which local edits are being discarded (all of them).
> >
> > They're telling me that perforce's (t)heirs option really does choose
> > the whole file, not just certain random hunks.
>
> I find that argument to be very convincing for update conflicts, but
> less so for merge conflicts... recall that (if we're merging branch
> changes to trunk, say) choosing repository now means "wipe out all
> differences between branch and trunk and leave us with an exact copy
> of the branch code". What does perforce do for the equivalent case
> for merges?

My best guess is that they assume you are not going to use the option
unless you know that is what you want, which is basically what we are
doing with svn resolved --accept option.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 18 18:28:34 2007

This is an archived mail posted to the Subversion Dev mailing list.