On Wed, Mar 13, 2002 at 05:17:27PM -0800, Bill Tutt wrote:
> > From: Ben Collins-Sussman [mailto:sussman@collab.net]
> >
> > IMHO, this is just becoming an out-of-control feature request.
> >
>
>
> Yeah, user interface heuristics can sometimes be useful, but I don't
> think this is one of them. Remember: In a binary file merge, nothing
> about the file might need to change, the user might just wants to
> overwrite whatever the last change was.
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?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- application/pgp-signature attachment: stored
Received on Thu Mar 14 03:18:17 2002