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 ar
Yes! I think that it should be enabled by default, and the user can put the -n option in his .cvsrc file for the affected commands, both for add and remove. The reasons for this: - It maintains comp
Contacting the server is not zero overhead. As Mark pointed out, it is much more compelling that users have complete control over conditions in their workspace and I would argue similarly for as much
This argument is not applicable to workspace changes. The user can manually edit the CVS/Entries files to add or remove a file locally without ever contacting the server. Your proposed hook would nev
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 ch
connect No! -n means "don't change the disk!" In other words, nothing is changed anywhere and the file would not be added locally. No, but to continue your logic, -C to request the validation would b
It's simpler, but neither safer nor saner to wrapper script around the client. The reason is this: If you enforce policy but give the user an avenue to circumvent it, the user will do so. If you're
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 ar
The latter *were* removed, over a year and a half ago, prior to the CVS 1.11.7 and 1.12.1 releases. References to the command option `-n' were removed from both the source and the manuals, for exactl
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