[Top][All Lists]

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

Re: CVS diff and unknown files.

From: Paul Sander
Subject: Re: CVS diff and unknown files.
Date: Wed, 2 Feb 2005 12:08:54 -0800

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

reply via email to

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