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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
