[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: diff3 followups

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-03-14 00:12:21 CET

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.

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).

Or I can spend a day or two doing the stuff above, which just doesn't
seem so important to me. I'd rather just stick with what we have for
now... unless someone feels really strong about this and wants to file
an issue.

---------------------------------------------------------------------
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:08:51 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.