Re: CVS diff and unknown files.

[Paul Sander]

On Feb 2, 2005, at 5:02 AM, address@hidden wrote:

> "Greg A. Woods" <address@hidden> writes:
> > [ On , January 31, 2005 at 20:30:21 (+0300), Sergei Organov wrote: ]
> > > Subject: Re: CVS diff and unknown files.
> > >
> > > Don't you wish to even try to understand the suggestion? The 
> > > suggestion
> > > is: invoke *the same triggers* both at 'cvs add' and 'cvs commit' 
> > > time,
> > > -- there is no need for separate triggers.
> >
> > No, using the same scripting hook at both add and commit times would 
> > be
> > bad, VERY bad.
>
> Sure. But I didn't in fact suggest it. I in fact argue in favor of
> absence of add-time hooks on the server at all. Let me try to explain,
> as the exact meaning of the suggestion has been somehow lost in the
> endless discussion with Paul.
>
> What do we exactly mean by add-time here? The time when "cvs add"
> client command is invoked, or the time when new file is to be committed
> to the repository using "cvs commit"?

I think we agree that add-time is the moment that the user invokes the 
"cvs add" command.

> If the latter, that is not the topic of this discussion.
>
> If the former, then server should not care/know about "cvs add" at all,
> so there is no such thing as "add-to-working-copy time" from the point
> of view of server, so there could be no server hooks invoked at this
> non-existing time, so these non-existing hooks can be neither the same
> nor different from commit-time hooks. In other words, I believe there
> should be no "cvs add" server command at all.

My argument has always been that, for certain policies that do not 
involve evaluating the content of a file (like enforcement of naming 
conventions) that there is value to having an add-time check.  The 
reason for this is that if certain classes of early actions are 
botched, it's better to find out sooner than later, because doing so 
can save the user from a lot of lost work.

So while you believe that add-time hooks are folly, there's another 
half of the community that thinks they're very useful.  Sergei, in the 
SCM world, there are many issues in which half of the community thinks 
one way, the other half thinks the opposite.  This is apparently one of 
those issues, at least with CVS.  There is no winning the argument on 
either side.  All that can be done is to build a solution that 
satisfies one side without inconveniencing the other side too much.

I believe that my proposal does exactly that.  To recap:
- Create an add-time trigger mechanism that
  - Has an interface identical to the existing *info files
  - Registers the add-time triggers in a new file, perhaps named 
"addinfo"
- On the client side and selected by the user, perform one of the 
following actions when the user invokes the "cvs add" command
  - Record the new file in the Entries file without contacting the 
server
  - Contact the server to run the addinfo trigger, recording the new 
file in the Entries file if the trigger complete successfully
- Run the addinfo trigger prior to any commitinfo trigger when the user 
invokes the "cvs commit" command

The reasons I believe this proposal satisfies all requirements are:
- Using addinfo triggers is a decision of individual projects.
- Users are not required to change their working habits.
- Users and projects that need add-time triggers get them.
- For CVS administrators, this is fully backward compatible.
- For CVS users, a new option to "cvs add" appears which either:
  - contacts the server by default but is defeated forever in one 
action or on the command line
  - does not contact the server by default but is enabled forever in 
one action or on the command line

In other words, it has zero impact on those who don't want or need it, 
but it's available to those who do.

> What I actually meant in the phrase you've taken out of contents and
> commented against is: iff somebody decides he needs to perform some
> checks on the server whenever user adds files to his working copy, he
> can arrange to invoke "cvs -n commit" after every "cvs add" (or as
> [optional] part of "cvs add"). This effectively makes *virtual*
> "add-time hooks" equal to "commit-time hooks" without any server-side
> "add-time hooks".

The problem is that if you reuse the commit-time hooks in this way, you 
are overloading that capability in a way that I (and apparently Greg) 
believe is not appropriate.

--
Paul Sander       | "Lets stick to the new mistakes and get rid of the 
old
address@hidden | ones" -- William Brown