[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: add hook question (was Re: Problem with importing third-party source

From: Paul Sander
Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
Date: Fri, 19 Nov 2004 15:43:59 -0800

On Nov 19, 2004, at 6:49 AM, address@hidden wrote:

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]