[Top][All Lists]

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

Re: Problem with importing third-party sources and adding/committing cha

From: Paul Sander
Subject: Re: Problem with importing third-party sources and adding/committing changes
Date: Wed, 17 Nov 2004 09:46:55 -0800

>--- Forwarded mail from address@hidden

>[ On Tuesday, November 16, 2004 at 23:53:40 (-0800), Paul Sander wrote: ]
>> Subject: Re: Problem with importing third-party sources and 
>> adding/committing changes 
>> Keep in mind that, although Greg does not acknowledge it, a number of 
>> people in this forum have stated a requirement for an add-time trigger 
>> that could be used for such things as enforcement of naming conventions 
>> and access control.  Such a feature (referred to in the past as 
>> "addinfo") would reinstate the need to contact the server during 
>> additions.

>Paul you keep spreading myths and mistruths.  I wish you'd stop.

This is simply not true, Greg, and you owe me a public apology.

>If you had more carefully considered the proposal I've outlined in its
>entirety and in its proper context you would have sees that there
>clearly is not any need at all, ever, for any contact with the server in
>order to enforce any arbitrary policy implementing checks for added new
>files, etc.

I understand your proposal clearly, which simply stated is a deferment
of all repository action related to additions until a subsequent commit.
This eliminates the need for the client to contact the server, assuming
that no other existing features change.

However, if additions are to be considered as triggerable events, and I
argue that they should be, then the server must be contacted regardless
of whether or not repository changes are deferred to commit time, so that
the trigger can fire on the server.

>_NO_ change to the repository is made until "cvs commit" time and the
>existing commitinfo hooks are _MORE_ than sufficient by far to implement
>any of the hacks you suggest some folks might need.

It's fine that no change is made to the repository until commit time.
I have no argument with that, and to that extent I encourage that your
patch be integrated into the definitive source.

I disagree with your claim that the commitinfo hook is sufficient.
Certain policies, like naming conventions, are best enforced at add time.
It's true that commitinfo could eventually catch naming errors, but
deferring that particular check leads to lost productivity while
corrections are made after the failed commit.

For an addinfo hook to work, the client must contact the server to fire
the trigger and read its completion status.  However, the addition of an
addinfo hook violates one of your preconditions, which is that the
existing behavior of CVS (outside of your patch) remains unchanged.

>--- End of forwarded message from address@hidden

reply via email to

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