info-cvs
[Top][All Lists]
Advanced

[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: Derek Robert Price
Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
Date: Fri, 19 Nov 2004 09:49:16 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

-----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.

>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.

>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 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?!?!?!?!?!?!?!?!??!?!?!??!?!?!?!??!?!

>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"!

Cheers,

Derek

- --
                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBngfsLD1OTBfyMaQRAmn4AJ9+3B1kKTQfbMOJdMxCdgMe0YTxeACgraCg
bo2U7p1D5br3lnh09k3qEp4=
=O5Zr
-----END PGP SIGNATURE-----





reply via email to

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