Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)

[Paul Sander]

On Nov 19, 2004, at 6:49 AM, address@hidden 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.