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

Re: conflicts, history, and the Principle Of Least Surprise

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-02-21 05:53:18 CET

Branko Čibej <brane@xbc.nu> writes:
> For text files, it would be *really* nice if we could make sure that
> the user can't accidentally commit a file that contains conflict
> markers. Since scanning the file is typically not enough, I'd suggest
> that we require some kind of user action to remove the "conflicted"
> state from the file, e.g., "svn ci --force" (which should behave like
> "svn revert" with --depth=0 and no implicit targets), or perhaps a new
> command (svn resolve?) would do it. This command could also remove the
> merge source files.

We could try out such protection, but let's do so after the main merge
functionality is implemented. I was also thinking of an "svn resolve"
command (no kidding -- same name!), but didn't want to complexify the
proposal by adding that at this stage. :-)

> Now a small wish ... It'd be nice if "svn up" could take a --no-merge
> option, so that it would *not* merge modifications into the working
> copy, but would only set the conflict state and provide the various
> versions needed for the merge. In fact --no-merge would be the default
> (and only) behaviour for binary files.

Similar reaction -- agree might be good, but it's last 10%, not first.

(Of course agree this behavior should be default for binary files!)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006

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.