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

Re: Locking consensus(es) so far

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-10-13 23:06:54 CEST

Ben Collins-Sussman <sussman@red-bean.com> wrote on 10/13/2004 05:01:58
PM:

>
> On Oct 13, 2004, at 4:12 PM, Mark Phippard wrote:
>
> > Ben Collins-Sussman <sussman@red-bean.com> wrote on 10/13/2004
02:58:53
> > PM:
> >
> >> Let me reiterate some agreements we seem to have reached, so far:
> >>
> >> - If update would produce conflict on a 'hijacked' file:
> >> print warning, then choose WC fulltext, backup repos
> >> fulltext.
> >
> > So that I am clear, if the update could merge the changes it would,
and
> > only if it couldn't it would create these files? I guess that is OK,
> > bit
> > I am still not 100% clear why it would not just create the same files
> > that
> > a merge conflict would create or why the situation is different.
> >
>
> The goal here is that the "non VC" user never ever sees a Conflict. We
> don't want non-techies to see a "C" next to a file, to have to
> understand the 3 fulltexts, or the 'svn resolved' command. Go look at
> the 'hijack' section of the UI document to understand this motivation.

I understood the motivation, I just didn't understand how the proposal
solved it. Also, what I am mainly interested in is that if someone uses
this feature with say a .c file, that I think it ought to work the way it
currently does. If the file is not mergeable, then I have no objection to
making it work differently. Although, personally, I think it should raise
the conflict and require you to make it resolved.

I guess the one change I think should be made, is that instead of creating
a .mine, the existing file should be the .mine, and then the .base and
.new versions should also be added.

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 23:07:53 2004

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.