Re: Commit inconsistency: Up-to-date check did not fail thoughitsho uld have !

[Kaz Kylheku]

On Mon, 3 Mar 2003, Mike Castle wrote:

> >- User B commits his changes to p, without first updating his working copy.
> >Against all expectations, user B succeeds to commit even though his working
> >copy is not up to date, leading to an unstable latest version of the project
> >in the repository.
> 
> Hmm... originally I was wondering, "How would this create an unstable
> latest version?"
> 
> The only scenario I can think of is where user B starts making use of a
> function that user A has changed/removed, and that function had never been
> used in that file before.

B could merely start making use of *semantics* which have been changed
or removed, but which are not reflected in any syntactic change.

Anyway, just because there is only one case in which some logic
provides value doesn't mean that you don't have to care about that
case.

In software there are often many special cases, which are handled by
logic which is unique to those cases. Any instance of such logic,
considered by itself, seems to provide little benefit---it just handles
this one silly case!

But working software is the sum total of all those little cases,
frequent ones and rare ones, being handled right, all the time.

Without solid statistical data, or other rational basis, you can only
guess about how frequently a case arises, so that you can make the
argument that handling that case is not worth the extra cost incurred
at other times when that case does not arise.

Maybe semantics changes that preserve the interface syntax do happen a
lot. Programming languages help detect syntactic breakages, after all,
but are not as helpful with semantic breakages. Changing the name or
syntax of an entity to reflect a semantics change is a pain for the
developer, because it requires lots of editing everywhere. 

So I suspect that semantics-warping without syntactic changing goes on
quite frequently; it's the easy, lazy thing to do, compared to properly
versioning the interface and semantics of something, whereby you invent
a new name if it doesn't work like the old one, and keep the old one
around for backward compatibility and all that.