[EMAIL PROTECTED] wrote: > Does anyone know of any pathes [sic] that will fix this problem? Well, CVS has two camps of users: 1. Those who use it because it's been designed to support concurrent development (read: no locks), and because they believe that a project where "communication" is accomplished via a software locking mechanism is doomed. 2. Those who use it because it's free, regardless of how it was designed. Ideally they'd like it to behave like all other version control systems they've seen, or at least don't really care about concurrent development (read: they like locking files). Because CVS was designed for (1) and only happens to be suitable for (2) by virtue of its price, what you're describing isn't really a problem--it's the way that CVS was designed to be used. It's interesting to note that locking is "possible" (not really) only because of two things: 1. The happenstance fact that CVS uses RCS files for storage 2. The happenstance fact that CVS was originally a bunch of scripts around RCS to (ironically) get around RCS' strict locking stuff so that it could support concurrent development and automatic merging, so it just happens to use the RCS administration system to administer the RCS files it manages 3. A perl script in the contrib directory that takes advantage of happenstance facts (1) and (2) above that simply resists checkin if the $Locker$ field is full. So cvs admin -l is actually a call into the old RCS administration system, and in fact doesn't do a damn thing as far as CVS out-of-the-box is concerned; it merely sets the $Locker$ field in the underlying RCS file. Presumably the converse, cvs admin -u, does the reverse. If you couple this little data-flipping switch with the locking script in the contrib directory--which just looks at the $Locker$ field and decides to resist checkin if there's anything there--then you get "pseudo locking", which regrettably now apparently means to folks that CVS "supports" locking. Short answer: it doesn't. Cheers, Laird
