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

Hash: SHA1

Paul Sander wrote:

>>--- Forwarded mail from address@hidden
>>Paul Sander wrote:
>>>It's true that add and commit hooks can enforce the same kinds of
>>>as post-conditions of the commit.  However, add hooks can enforce
>>>like naming conventions.  I'm working in a shop right now that
prefers to
>>>have additions to the source tree (particularly new directories) be
>>>by the architects of the project rather than the rank and file, and
>>such a
>>>policy is best enforced at add time.
>>>The reason why I say these are best done at add time is because if the
>>>add succeeds then the user is likely to do a lot more work under the
>>>assumption that the subsequent commit will succeed (or at least not
>>>due to conditions created by the add).  If the commit fails due to an
>>>improper add, then the user must re-do (or un-do) a bunch of work.  All
>>>those hours of lost productivity could have been avoided by an add-time
>>This might be true, but it seems to me that most damage due to your
>>"lost productivity" could be fixed with a rename or two and maybe a
>>few `sed' runs, in a few minutes.  At least in an environment where
>>most of the files concerned were text files, as will usually be the
>>case using CVS.
>It depends on the nature and extent of the changes.  I can easily imagine
>scenarios in which lost productivity would be measured in days, even
>assuming that all files are ASCII.
>>It might be interesting to see Greg's patch, but yours wouldn't be a
>>big deal either, I think, as long as the add went forward without the
>>hook execution when the server could not be contacted.
>The thing is, if there's a triggerable event, the trigger must be able
>to halt the event.  Unplugging the network interface to enable adding a
>directory is simply not acceptable.  On the other hand, requiring all
>add hooks to be replicated at commit time would eventually catch the
>error, and it could be argued that someone who attempts such tricks
>gets what they deserve, but it's just easier and better all around to
>just make the trigger act like a trigger.

I still disagree, because some people like working from their laptop
and wireless network connections are hardly ubiquitous yet.  Work that
a developer can do from their laptop off of the network can also
provide additional productivity.  It also means work a developer can
do while the server is down.

Perhaps a -C option to `cvs add' similar to `cvs edit', where -C can
be placed in the user's .cvsrc for the add command and the add will
not be allowed unless the server contact and verification is successful.



- --

Email: address@hidden

Get CVS support at <>!
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

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