[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: Mark D. Baushke
Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
Date: Thu, 18 Nov 2004 11:47:40 -0800

Hash: SHA1

Derek Robert Price <address@hidden> writes:

> Mark D. Baushke wrote:
> > Hi Greg,
> >
> > Is it reasonable to suggest that a addinfo trigger could be run as a
> > part of the 'cvs commit' command should the client not happen to connect
> > to the server for a 'cvs add' operation?
> It should probably run regardless since it would be much simpler than
> securely tracking whether the add on the client side had contacted the
> server.

Good point.

> > The idea would be that having simpler triggers for various kinds of
> > policy makes the administration of a repository easier.
> >
> > In a similar manner a trigger for 'cvs rm' could be implemented to
> > impose policy.
> Sure, but again, not by default.


> > The timing of WHEN those triggers get invoked is what seems to be the
> > sticking point for folks... Like Derek, I would not mind a hack to
> > allow a
> > the users to perform a check that all is well... perhaps a 'cvs -n
> > commit'
> > should run those validation checks?
> That's a good point (and I believe that `cvs -n ci' will aready run
> any validation checks in place on the commitinfo hook), but allowing
> them to run from `cvs add -C' might be slightly more convenient and I
> still argue should be a simple enough addition after Greg's change.

Given we do not currently have those hooks, I have no objections to
considering a patch that does this.

> > I have no objections and would in fact LIKE to see disconnected
> > operations for 'cvs add' if possible. I also suspect that changes to the
> > 'cvs import' mechanism would aslo be useful.
> Yep.
> > For that matter, I would like to see disconnected 'cvs diff' commands
> > where possible for users that already have a CVS/Base/* version of the
> > file around...
> Yep.  I'm actually tempted to have the CVS client always create the
> CVS/Base files for just this reason.  I think that `cvs diff' against
> the base revisions is by far the common case but I hadn't completely
> convinced myself that it was worth the overhead of the duplicate files
> yet.  It would have the secondary side effect of allowing `cvs unedit'
> in disconnected mode even when files had not been `cvs edit'ed and
> should be another fairly simple change.  :)

I recommend this be an option that could be requested by the user or the
default behavior switched by the CVSROOT/config file. I know of some
projects where there will be insufficient room to hold multiple copies
of the tree on disk at the same time and it might be desirable to allow
the administrator to default the behavior desired with the user able to
do an override.

        -- Mark

Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

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