2024-10-23 10:12 AEST by Arthur Barrett - When operating CVSNT servers for long periods of time, users and particularly administrators are prone to 
making procedural mistakes.

eg:
we can set up ACL's on a repository to ensure that the branches are 'reserved' and the promotion levels are 
not.  part of the ACL system even lets us specify warning messages when unauthorised users attempt to 
make unsafe changes  (-m "Show customised error message when access is blocked due to this entry.")

But what if an administrator makes a change that has serious implications and the designers did not expect?

eg:
cvs up -k-x FILEDAT.USERS.TRG

This would permanently remove the 'reserved mode' for this file.

It would be nice to have some more advanced rules that designers can use to help prevent these errors 
during long term ownership.

eg:
1) this could be a new type of ACL, eg: meta (for attributes of files)
2) some 'rules' trigger
3) both?


To help design this we should start to collect a list of the sort of things we'd want to look for.  Ultimately that 
will probably determine the design of the system.

Ideally we'd want an administrator to be able to override this warning.  But the simple requirement of using '-
f' would probably just result in administrators always using -f, and therefore never being encumbered by the 
error.

Having a 'must submit twice' rule is difficult for CVSNT server to enforce, but maybe the lock server could 
provide this sort of feature - basically a different sort of 'file lock' that requires a number of repeats. Indeed 
this would be better implemented in cvslock than cvsmanager in cluster based installs, which share one 
cvslock for several cvsmanager services.

An alternative would be to require some sort of password/key to unlock.

Even better would be both.

one try.
two tries - now requires keycode
now key code.


In this way the key code could be auto-generated.  Like a robot test.  So this would make it very difficult to 
script to hardcode.

There would need to be some sort of 'special case' where many files were being changed - you wouldn't want 
to need to do this for each and every one of 2000 files...

Maybe there also needs to be a prompt?
You are attempting to change 'xxxxxxxxx' but a rule exists to prevent this.
1. to commit the change but without 'xxxxxxxx' use 'cvs ci -Q'
2. to override the rule, commit again to get a one time code

eg:
You are attempting to change 'reserved mode' but a rule exists to prevent this.
1. to commit but without changing 'reserved mode' use 'cvs ci -Q'
2. to override the rule, commit again to get a one time code

variations:
-  'reserved mode'
-  'file mask'  (or 'execute permission')
-  'binary or text'