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

Re: Explanation on the conflict and "svn resolve" functionnality

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-04-06 17:34:08 CEST

On Tue, 2004-04-06 at 05:19, Alexis Boutillier wrote:

> I thinked it is dangerous to allow the resolution of a conflict by only
> deleting two files.

Why is it dangerous?

The Subversion developers were trying to solve a very specific problem
in CVS: namely, that it's easy to forget that a file has conflicts,
because CVS *only* tells you about the conflict during an update. The
'C' might scroll off the screen, and then you forget about it, and then
you accidentally commit the conflict markers. It's a common CVS

Our solution to this problem was make "conflicted" into a "sticky" state
that must be explicitly un-done. In other words, the user must *tell*
Subversion that they've dealt with the conflict, in order to make the
file committable again.

The question is, how does the user tell Subversion that they've resolved
the conflict? There are 3 different ways to do it:

  1. run 'svn resolved', or
  2. remove the fulltext tmpfiles, or
  3. remove the conflict markers in the file.

The problem is that #3 is impractical; there's no reliable way for
Subversion to know whether a conflict marker exists because of a
conflict, or because it's a legitimate local modification. So we tossed
out option #3. As a result, options 1 and 2 are still legitimate ways
to tell Subversion that the conflict is resolved.

Make sense?

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 6 17:36:04 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.