> From: Ben Collins-Sussman [mailto:email@example.com]
> Karl Fogel <firstname.lastname@example.org> writes:
> > Kevin Pilch-Bisson <email@example.com> 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
> > > be modified. The other option would be to grep the file for the
> > > markers, but I think that is overkill. Other's have pointed out
> > > they might want to actually check in a conflicted file, but I
> want to
> > > make it too easy.
> > Oh, checksum is definitely better, thanks for pointing it out. If
> > goal is to determine whether the file has been modified, nothing
> > 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
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
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Mar 14 02:17:59 2002