Good point
>
> > At this very second, the conflict files' existence are the sole test
> > for whether a conflict still exists or not. Works great, why make it
> > more complex?
> >
> > In 5 minutes, I can create 'svn resolve', which just removes the three
> > backup files, thereby making it easier to "resolve" the conflict --
> > and solves just about the only complaint over the status quo (user
> > convenience).
> >
>
> I'd rather have the 'svn resolve' command and force the user to accept
> the result of any merge conflict. This would mirror into a UI action to
> mark the conflict as resolved. (As opposed to VSS's silly question upon
> invoking a Checkin: "Are you sure you've resolved all conflicts?") Make
> the user be a responsible developer and manually have to resolve the
> conflict.

I now agree with this approach instead. Firstly, it does make more sense for
binary files. Secondly, it is a clearer interface than "You have to change
the file before you commit." It instead becomes "You have to run svn resolve"
to mark the changes as resolved. One question though, does svn resolve do
anything other than remove the three backup files?