[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:17:34 CEST

On 7/18/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 7/18/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> > On 7/18/07, Erik Huelsmann <ehuels@gmail.com> wrote:
> >
> > > Aren't they just 2 different use-cases ('select-theirs-entirely' or
> > > 'select-theirs-hunk-wise')?
> >
> > I don't know of any VC system that offers both of these options. I've
> > only seen users concerned about resolving conflicted hunks; I can't
> > imagine a situation where the user would want to resolve conflicted
> > hunks *and* toss out other local edits at the same time.
>
> 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 am in favor of doing what other tools do. These docs would seem to
support your co-worker's claims:

http://www.perforce.com/perforce/doc.052/manuals/cmdref/resolve.html#1040665

I read through the ClearCase manual and could not find any evidence
that ClearCase supports an option like this. They seem to require you
to deal with conflicts.

-- 
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:16:43 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.