Tim Ellison wrote: > Yes it does, your commit will fail if I have the lock; but I am abusing > it to achieve a somewhat different goal of 'inadvertent modification'.
OK, we both agree on the "abuse" part. ;-P > If we cannot contact the lock holder we simply break/steal the lock. Right. But, locks should only be used for files which require serialized modifications, such as binary blobs. Other commit control should be made through pre-commit scripts. > Not really. I can add the warning, but I was looking for a way to > ensure people did not mistakenly change String or did not read the > doc/dev list. By failing people's commit and making them explicitly > acquire the token first they have to know what they are doing. So, you should investigate a pre-commit script based approach. For example, you could require a harmony:string-revision property on the String.java file. The pre-commit script would check that any commit increases this revision by one; if not, then an explicit (custom) error message can be given. Quite easy to achiev with svnlook, etc. What do you think? Etienne -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
