On Nov 19, 2004, at 6:49 AM, [EMAIL PROTECTED] wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paul Sander wrote:
There is a certain logic to having triggers gate changes to the repository. There's also a certain logic to having a tool prevent conditions that will later cause it to fail. Uncommitable changes are such a condition, and it simply makes no sense to allow adds to succeed when we know that committing those adds will fail.
It does when they user is disconnected from the network or wants to generate a patch to mail to someone for review without committing the changes, at the least. The user should be able to make any changes they wish in their workspace. The server should only gate changes to the repository, except possibly when the user requests otherwise.
Fair enough.
There's another point I'll make but won't argue over: There's a limit to the amount of control a user should have, even over his own workspace. The user shouldn't be able to corrupt his metadata to the extent that it causes failures, for example.
Duh, not via CVS anyhow. They can do anything they want with other tools in their local workspace. I hope you are not proposing CVS run setuid root and prevent the user from altering their own files? Regardless, I am hardly proposing that CVS destroy a user's metadata.
Actually, all I'm suggesting is that we should maybe consider ways of moving CVS metadata out of the user's workspace. But that's a different argument, and one that I'm not willing to pursue right now.
Why is having CVS aware of source files an enabler for producing patches?
CVS will not generate patch data for files it is not aware of. For a new file to be "listed" in the diff, it needs to be added first.
I don't consider triggers to be "conveniences." If they are to enforce
policy then they can't be defeated by the user.
Your suggestion would be easy to defeat, regardless, and no policies should be enforced on the user's workspace without their request.
This assumes that policies as set by project management are voluntary. People who bypass them have a way of affecting the project in ways that management won't tolerate for long.
This is why I hate the -n option of the checkout/commit/tag/update commands and advocate its removal from CVS.
What in the world are you talking about??? -n prevents changes from being made anywhere! On the server or in the workspace! Why in the world would you care if the user can run a command which does nothing except tell the user what it would do if they actually ran it without - -n?!?!?!?!?!?!?!?!??!?!?!??!?!?!?!??!?!
Kindly double-check the manual and the code. There's this:
cvs -n commit ...
and there's this:
cvs commit -n ...
There's a difference. The former means "don't change disk". The latter means "don't fire *info triggers". I believe that the latter should be removed, but that's just me.
However, if applied to the add command, it is more agreeable than the -C option as described above for human engineering reasons.
Again, no! -n prevents any permanent changes from being made to the disk, anywhere! (I mention permanent because some temp files are created and used in the /tmp dir, but these are conveniences and safely go away when the command is finished so are irrelevant for our purposes.) `cvs -n add' would mean, "CVS, tell me what `cvs add' would do, but don't change anything", meaning "don't add the file"!
What I've been trying to say is that the following is agreeable:
cvs add -n ...
If this form of -n remains compatible with the other trigger no-op options (like cvs commit -n ...), then it could be put in the user's .cvsrc file to defer add-time triggers until commit time.
_______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
