Neels J Hofmeyr wrote:
> C. Michael Pilato wrote:
> > Julian Foad wrote:
> >> On Mon, 2008-10-20 at 14:54 +0200, Stefan Sperling wrote:
> >>> On Sat, Oct 18, 2008 at 02:00:39PM +0100, Julian Foad wrote:
> >>>> * There must be a way to use "svn merge" to merge a required change
> >>>> into a WC to resolve a tree conflict. (The merge currently fails if
> >>>> there is any conflict already flagged, which is usually the desired
> >>>> behaviour, but not when you're trying to resolve a conflict and need to
> >>>> use a merge.)
> >>> What about making a merge into a tree conflict victim conditional
> >>> on the popular --force switch?
> >> Yeah, maybe that really is a valid use of "--force". It looks like a
> >> reasonable solution to the problem.
> >>
> >> (I hereby swear that this really is me saying this. :-) )
> >
> > Haha. I'm going to need you to resent your mail, PGP-signed by yourself,
> > before I buy this. ;-)
> ...Hm. How about more like a specific --ignore-conflicts option? What else
> would `merge --force' entail? The online help only says "--force force
> operation to run". What if I want the existing conflicts ignored but don't
> want these other effects, whatever they may be, badly documented as they are?
Quite right. Don't know where my mind was yesterday.
> I, too, don't like --force, except when it's synonymous with a list of other
> options.
Ah, now, that's a good idea. One of the major problems with a "force"
option is wanting only one meaning and getting several. Another is not
being clear on exactly what it means. If we could say, "equivalent to:
--x --y --z" that would be much better.
> Also, what is the reason why it should be disallowed at all to merge into a
> working copy with conflicts? They are just local changes after all. Is it
> only about conflict markers in text files?
Conflicts are not "just local changes". A normal, non-conflicting merge
results in just local changes. A conflict results in a set of possible
local changes, among which the "correct" set of local changes has not
yet been chosen. Without knowing how the first conflict is going to be
resolved, the only way to merge a further change into this intermediate
state would be to merge it into all of the possible outcomes of the
first conflict, and record what happens in each of them. And of course
this "set of possible changes" is an infinite set.
Throughout Subversion we are pragmatic in saying that if two changes
don't touch the same files and directories, they are reasonably
compatible and we should go ahead. As always, it is ultimately the
user's responsibility to find any logical (semantic) conflict that may
be caused by applying any two changes.
In the case of tree conflicts, it is especially likely that the
resolution will involve a file or directory that was not marked as being
in conflict. Therefore, the most conservative approach would be to
disallow any merge into a working copy that has any conflicts in it.
However, we can see at a glance that that would be far too restrictive,
so allowing a merge to proceed as long as it doesn't touch an item
marked as conflicted seems like a good compromise.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-21 15:39:19 CEST