[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

> On Oct 13, 2004, at 4:12 PM, Mark Phippard wrote:
> > Ben Collins-Sussman <sussman@red-bean.com> wrote on 10/13/2004
> > 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,
> > 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.


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.