Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Maybe it's just a matter of creating a server option to explicity disable -x option the same way we can enforce its use by editing cvsrc. Regards, Alexandre > -----Original Message----- > From: cvsnt-bounces at cvsnt.org > [mailto:cvsnt-bounces at cvsnt.org]On Behalf > Of Jerzy Kaczorowski > Sent: Monday, October 04, 2004 7:37 PM > To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > Subject: Re: [cvsnt] Re: Why edit -x? > > > Tony, > > Exclusive locks are like cancer - they spread and reach the > point of no > return very quickly because they penalise anybody trying to work in a > concurent way. > > After not being able to complete their work because of > somebody's locks > people learn to reserve the files they want to work with (and > a couple extra > just in case they need them later). There is no easy way out > of that vicious > circle. It just becomes a rutine and reduces version control > system to a > mere backup system. > > In the case of exclusive edit there is a simple remedy to the above > scenario: allow to override the lock. It doesn't have to be > simple but it > should not involve external intervention (admin override is > not an option, > most admins doesn't want to touch things like that). > > It would not be the first time - the old admin locks (admin > -l) allowed > anybody to unlock the file by giving revision explicitly > (admin -urev). > Majority of users, and most of those using locks, didn't > realize that and > locked themself happily to death, yet it allowed a smart > person to unlock > the files and complete their job in concurent fashion shall > the need arise. > > Perhaps a similiar approach can be applied to a new option? > > Best Regards, > Jerzy