> From: Ben Collins-Sussman [mailto:sussman@collab.net]
>
> Karl Fogel <kfogel@newton.ch.collab.net> writes:
>
> > Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> > > Honestly, I don't like the idea of just the timestamp. I think it
> would be
> > > good to record a checksum instead. That way at least the file
must
> actually
> > > be modified. The other option would be to grep the file for the
> conflict
> > > markers, but I think that is overkill. Other's have pointed out
times
> when
> > > they might want to actually check in a conflicted file, but I
don't
> want to
> > > make it too easy.
> >
> > Oh, checksum is definitely better, thanks for pointing it out. If
the
> > goal is to determine whether the file has been modified, nothing
beats
> > a checksum. To be really complete, we'd record
> >
> > - a timestamp
> > - a file size
> > - a checksum
> >
> > in the entry, to get the most efficient possible modifiedness check.
>
> 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.
> 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.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 14 02:17:59 2002