Re: CVS diff and unknown files.

[Sergei Organov]

Paul Sander <address@hidden> writes:
> On Jan 30, 2005, at 6:40 AM, address@hidden wrote:
> 
> > Paul Sander <address@hidden> writes:
> >> On Jan 28, 2005, at 8:50 AM, address@hidden wrote:
> >>
> >>> Paul Sander <address@hidden> writes:
> >>>> On Jan 27, 2005, at 1:07 AM, address@hidden wrote:
> >>> [...]
> >>>>> Just to understand your point better, do you propose 'cvs add -c
> >>>>> new_file' and 'cvs ci new_file' run exactly the same set of triggers?
> 
> >>>>> Different sets?
> >>>>
> >>>> I think the consensus in the last iteration of the topic was that, if
> 
> >>>> add-time triggers were implemented, they would run as a client-side
> >>>> option at add-time and and be obligatory at commit time, preceding
> >>>> commit-time triggers. Doubling the overhead was the only way we came
> >>>> up with at the time that guaranteed that the add-time triggers fired
> >>>> at least once prior to the first commit of a new file.
> >>>
> >>> Well, so the answer to my question is "the two trigger sets are
> >>> different". But it in turn means that it could be the case that I won't
> >>> be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said
> >>> the file is OK to be added. IMHO that's a mess. And I believe this mess
> >>> is direct consequence of poor design choices you are advocating, sorry.
> >>
> >> A commitinfo trigger can always refuse a file for which "cvs add"
> >> completed successfully. There's nothing new here. If you don't like
> >> that, then don't use commitinfo.

I propose to use commit-time triggers by "cvs add -c" time instead of
special add-to-repository-time triggers.

> >
> > In my design the triggers are the same, so there is no such problem.
> > Either the file is OK for repository or not, -- simple and clear. The
> > less problems, -- the better.
> 
> Okay, don't use the add-time triggers in your shop. No one is forcing
> you to.

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.

> > In your design there is "OK for addition, but wrong for commit" that
> > IMHO is a nonsense. I believe such a design is seriously flawed, sorry.
> 
> Wait a second.  The "OK for addition, but wrong for commit" is exactly the
> status quo.

Yes, but you propose to improve this using some new thing called
"add-time" triggers, and I try to explain that you will get even better
results if you invoke commit-time triggers at add-time.

> The "cvs add" command succeeds, "cvs commit" fails due to commitinfo.
> What I'm proposing is "bad for addition, bad for commit", where "cvs
> add" fails on those occasions when we know at that moment that "cvs
> commit" will also fail.

Why don't just run *the same* script on addition to see if it would
actually fail? Why do you need *separate* scripts?

> That's not to say that we will *always* know at add time that the
> commit will fail; failures can occur due to problems in their content
> which are clearly not ready to check at add time.

Well, if I understand correctly, your intentionally want to have weaker
checks at add-time than at commit-time. Instead, you can do it in the
commit-time trigger by skipping some of the tests if the file in
question is new one.

> >> What's new is that we can cause "cvs add" to fail under certain
> >> conditions that we know in advance will cause commitinfo to refuse a
> >> file. To make sure that the condition is checked, we do it a second
> >> time before commitinfo, because some users insist on defeating it the
> >> first time.
> >
> > What functionality is lacking? "cvs -n ci" allows you to do it. All you
> > require is "cvs add" to *enforce* the checks. I have two levels of
> > objection here:
> >
> > 1. Enforcement by "cvs add" of the checks doesn't require introduction
> >    of separate "add triggers" as usual "commit triggers" could do the
> >    job as well.
> 
> My argument is that it does not in fact "do the job as well."  I've given a
> number of reasons why in earlier messages.

No, you didn't. Or at least I somehow missed them. The fact that
currently CVS doesn't invoke any triggers at add-time has nothing to do
with my objection. The question is what is so different about add-time
triggers from the point of view of *server* so that it's not enough to
just invoke commit-time scripts at the add-time?

> 
> > 2. Enforcement by "cvs add" of the checks is wrong idea by itself as CVS
> >    is not a project management tool and should not be. If your project
> >    indeed requires such things, let users execute your wrappers instead
> >    of direct CVS commands.
> 
> Wrappers are not capable of enforcing policy by their nature.  Triggers are.
> I've explained why this is so, also.

You've indeed tried to explain, but I don't see anybody but you who
agrees with the explanation. One of my argument is that triggers, being
run on the server, have no way to impose any policies with respect to
working copies, which are under the full control of clients.

[...]

> >> Can you suggest another way to enforce add-time policy in a way that's
> >> centrally controlled by the CVS admin?
> >
> > Sure. Commit triggers. If "cvs add" is capable to invoke them, if it
> > invokes them by default, and if trigger failure results in a warning or
> > in error are additional concerns. The primary concern is that separate
> > add-time triggers are not required.
> 
> Hmmm... I'm not exactly understanding what you're saying here. Are you
> suggesting that commitinfo be used at the time that "cvs add" runs? (I
> know you've recommended that users invoke "cvs -n commit" right after
> "cvs add", so I just want to check my understanding.)

Yes, exactly, and I try to get an answer from you why is it a bad idea,
but instead you just continue to insist add-time triggers are the only
answer to the problems you are trying to solve. Maybe I'm missing
something simple and obvious, but still you didn't tell me what it is. 

> If I do in fact understand you to be recommending that commitinfo be
> used at add time, then I must disagree. Triggers used at commit time
> to check the content of files (like Greg's RCS Id trigger, for
> example) are not appropriate to use at add time. Things like checking
> that the user has the right to add a file, or checking that the name
> of the file complies with policy, are legitimate to check at add time.
> They can also be checked at commit time, and the current proposal does
> that because the add-time triggers are optional.

So the only thing you need to know in the commitinfo is what user is
trying to do and decide what checks are required based on this
information. If commitinfo currently doesn't have all the required
information, maybe it's better to fix it instead of inventing yet
another hack in the form of add-time triggers?

> > BTW, if you believe your project indeed requires it, arrange wrappers
> > that clients will run instead of "cvs add". In fact, as you requirements
> > are in the field of project management, your users should never invoke
> > CVS commands directly, -- it's the job of your project management tool
> > to invoke CVS commands when required.
> 
> That's a common workaround.  But wrappers are not enforcers.

Turn them into enforcers if you wish.

> If users think the wrappers are in their way, they'll drop down to CVS
> to add the file, causing more significant breakage later.

Either trust your users or arrange things so that it won't be possible
for them to invoke cvs commands directly. But even if you choose the
latter way, those that do think the wrappers are in their way will
probably find a way to bypass them anyway.

> It's at that time that they finally learn the value of the process.

If somebody prefers to learn on his own mistakes, -- let him do it
unless it doesn't break others work.

[...]
> >> BTW, the definition of "client/server" implies the presence of a
> >> network for communication between the two parts,
> >
> > Wrong. Client and server can work on the same computer without any
> > network. Moreover, client/server idiom is heavily used inside
> > "monolithic" programs as well. Basically, client/server only means that
> > there is some "server" that makes some operations on behalf of
> > "clients", how clients communicate with the server is a secondary issue.
> 
> While your statement is true, the fact is that client and server
> programs typically operate on different machines. The fact that they
> do is what gives the client/server paradigm its power. Sure, I can
> write client/server programs that use loopback interfaces, Unix domain
> sockets, or even named pipes, but they offer no benefit because
> function calls are more efficient RPC calls.

Don't you aware that client/server paradigm is widely used inside
"monolithic" programs as well? There are always things left to be
learned in this world.

> >> without which the application fails.
> >
> > Which part of it, client, server, or both? Server should never fail,
> > client will fail only if an operation that indeed requires to contact
> > the server has been requested. That's how things are supposed to work in
> > client/server applications. Your limited idea of client/server
> > applications is noticed, but can't be agreed upon, sorry.
> 
> Oh, I agree with your point.  But what good does that do the user?  From his
> point of view, he gives a command and it fails.  He doesn't care why.  And
> that is how I define "the application fails".

I, as a user, do care if I can't do something just due to somebody
designed things so that essentially local operation requires to contact
server and the link or server is down, sorry.


[...]
> > To aid this it's enough to make it possible to run commit-time triggers at
> > add-time. No invention of separate ugly "add-time triggers" is required.
> > That's what I'm trying to explain.
> 
> Indeed.  The thing is, the add-time triggers are different from the commit
> time triggers.  Recall the proposal:
> 
> - Implement optional add-time triggers in "cvs add".
> - Implement mandatory add-time triggers in "cvs commit".
> - Make "cvs commit" run the add-time triggers before commitinfo.
> 
> The specific reason for this is because add-time policies are a subset of
> commit-time policies.  The two simply cannot be merged.

And here is alternative: invoke commitinfo triggers on any change and
let them decide which checks should, and which shouldn't be performed.

[...]
> >> But think about what's really going on. If the work will be refused
> >> anyway, why would you possibly want to deliberately proceed toward
> >> a dead end?
> >
> > OK, the repository told me it won't accept my changes. In my particular
> > case it was due to the fact that I don't have write access to the
> > repository. And here is actual problem. I need the files to be added to
> > the working copy anyway.
> 
> Okay, touch them and go on your merry way. Or opt out of the add-time
> check. What seems to be the problem here?

Well, you've asked "why would you possibly want to deliberately proceed toward
a dead end" and I tried to provide an example when the end is not
actually dead. The problem is that unless I add the files, 'cvs diff'
doesn't work on them, and if your proposal is implemented, and I bypass
the add-time checks, I have no way to repeat them later without
committing the files.

> >> If you really, really want to go that route, the add-time test is
> >> optional anyway.
> >
> > What I really try to explain is that an ability to have
> > add-to-working-copy time tests don't require invention of add-time
> > triggers. Ability to invoke commit-time triggers at add-to-working-copy
> > time is sufficient and I believe is better alternative to add-time
> > triggers.
> 
> See above.  The sets of add-time and commit-time triggers are
> different.

For the policy you have in your mind they are different, for a policy
somebody else needs they are the same. Why do you need to invent new
thing, add-time triggers, if commit-time triggers can do the job
provided they have enough information to make the right decision?

> >> What you do privately in your workspace isn't my concern. It's just
> >> that once you make CVS aware of the file, you must become aware that
> >> certain policies begin to apply. I find it more efficient to detect
> >> violations early because history has shown that problems are easier,
> >> faster, and cheaper to fix when found earlier than when found later.
> >
> > You once again state this point of early detection. However, I didn't
> > see anybody arguing its validity. The problem is that your "make CVS
> > aware of the file" is not well-defined. Some people here argue that
> > "make CVS aware of local file addition" is not the same as "making CVS
> > repository aware of the file addition", and the former has in fact
> > nothing to do with the repository and the server. If you need CVS server
> > to be aware of the additions to the working copies, just do it, i.e.,
> > invoke "cvs ci -n" early. Adding corresponding option to the "cvs add" for
> > convenience won't be a big problem either. All this doesn't require any
> > special "add-time triggers".
> 
> I agree with most of what you say here, but let me clarify something:
> The purpose of add-time triggers is not necessarily to "make the CVS
> repository aware of the file addition". The only reason to contact the
> server is to run the trigger. This in no way implies that they should
> have side-effects, and in fact I would argue that triggers that create
> side-effects are bad. The idea here is to perform tests only.
> 
> Commit-time triggers typically do more than what add-time triggers can
> call for. And in fact, the loginfo feature (which hasn't been
> mentioned before but also runs at commit time) is typically used for
> the specific purpose of creating side-effects.

I still fail to see how it is better to have separate triggers than
having one trigger that decides what to do itself.

> >>>>> In fact the semantics of proposed 'cvs add -c' is: "add this
> >>>>> file to the working copy and check if the repository will allow
> >>>>> me to commit this new file if I decide to". In this semantic
> >>>>> only the latter part has anything to do with the repository, and
> >>>>> it is "commit", not "add", that's why I suggested 'cvs commit'
> >>>>> would be more logical place to check
> >>>>> for such things.
> >>>>
> >>>> Certain conditions that "will allow me to commit this new file if I
> >>>> decide to" can be checked at the time the user invokes the "cvs add"
> >>>> command. The rationale is that if a failure condition can be detected
> >>>> at add-time then any conditions deriving from those creating the
> >>>> failure condition can be halted, thus avoiding costly recovery action
> >>>> at the time when the first commit actually fails.
> >>>
> >>> The problem is that you still try at add-to-the-working-copy time to
> >>> impose policies that in fact make sense at the add-to-repository time.
> >>
> >> There's nothing I can say here that I haven't said before: The
> >> commit will fail anyway, so why not find out early and fix it while
> >> it's still easy?
> >
> > No reason, -- just do it. Invoke commit-time triggers as early as you
> > wish. That will give you the most authoritative answer about validity of
> > your addition.
> 
> See above.  The add-time triggers are a subset of the commit-time triggers.
> Commit-time triggers do things that are not appropriate at add-time.

Ah, so the sole purpose of invention of add-time triggers is in fact an
attempt to don't break compatibility with the current commit-time
scripts, right? If so, it's better to explicitly state it to avoid
misunderstanding similar to mine.

[...]
> >> Seriously, think about what you're saying.  You want to do the following,
> >> dramatically oversimplied:
> >>
> >> edit foo.h
> >> cvs add foo.h
> >> edit foo.h
> >> cc FOO.C
> >> cvs commit foo.h
> >>
> >> It's at this point you want to fail, after you've done all the
> >> work. In my opinion it's better all around you fail after two
> >> steps, not five.
> >
> > You've missed my point. I have nothing against step2 warns me about the
> > problems, maybe even by default, if I still have ability to suppress the
> > warnings. I'm strongly against step2 to refuse to add the file as I
> > believe it would just disturb instead of help: if step2 refuses to add
> > the file, it doesn't prevent me from doing steps 3 and 4. In fact it
> > even doesn't prevent me from invoking 'cvs commit foo.h', but instead of
> > getting comprehensive explanation from the server why my change isn't
> > accepted, I'll get less useful message "run cvs add first".
> 
> Are you saying that if step 2 fails, you would proceed with steps 3
> and 4 and maybe attempt 5 without correcting the failure condition?

I said what I said, your suggested _failure_ to add the file to the
working copy doesn't prevent me from doing the rest of steps. It means
that it's not any better than _warning_. And I even showed why it is
slightly worse.

> Why in the world would you do that? Seems to me like you're trying
> very hard to walk yourself down a dead. If that is indeed the case,
> then you get what you ask for: Lost time and effort.

If all the user always did only right things, why in the world would you
need those add-time checks in the first place?

> >> Sure, you can change your behavior and move the add down to right
> >> before the commit, and that is consistent with the working styles
> >> of many people, but then they get what they ask for.
> >
> > So even with you proposals implemented you fail to actually impose
> > policies you are trying to impose with the proposals, -- too bad.
> >
> > That's another thing I'm trying to explain, -- you have no way to
> > actually impose policies on the client side. Thinking otherwise is no
> > more than self-delusion.
> 
> Well, that's what I get for pandering to the crowd that thinks that
> they simply must be able to add a file while working offline. If an
> add-time connection to the server were a requirement (i.e. there were
> no feature to opt-out of add-time triggers) then this wouldn't be a
> problem. Don't blame me for trying to meet your requirements.

I don't. I blame you for the failure to meet your own requirements. Even
if you make invocation of triggers by "cvs add" an absolute must, the
users will simply don't run "cvs add" for days until they need to commit
their changes due to your own expectations of your users behavior.

> >>> However, I still believe "cvs add" is a wrong place to implementing the
> >>> functionality from the design point of view. I can only repeat my
> >>> argument: as "cvs ci new_file" will do the checks anyway, that's what
> >>> "cvs -n ci new_file" should do, not "cvs add". The same opportunities
> >>> for the user, but cleaner and simple design.
> >>
> >> But it's a lousy user model because it allows the user to proceed a
> >> long way down a dead end before turning him around.
> >
> > Well, the fundamental difference of my proposal is that it doesn't
> > require special add-time triggers by replacing them with the ability to
> > invoke commit-time triggers as early as possible. Does "cvs add"
> > actually invokes these triggers (either by default or not), and if the
> > result of invocations is a warning or an error, are additional concerns
> > that could be decided upon afterwards. The main of my points still is:
> > "there is no need for special add-time triggers as commit-time triggers
> > can do the job better".
> 
> Nevertheless, the two sets of triggers are different,

In your proposal, they are, I understand that from very beginning.

> and running commit-time triggers at add-time is not appropriate.

Why? Because it doesn't match the policy you have in mind? Then change
you commit-time triggers so that they don't do some tests at add-time.

> Like I said in another post, after the commit has completed, the
> effects of the two implementations are identical.

> What we're arguing about is what's the right way to make the journey
> to that point. My way has merit.

Sorry, but the only real merit I guessed is backwards compatibility with
current commit scripts. Anything else?

> >>>>> To get your semantics, it seems you need a new operation with the
> >>>>> semantics "add the file to the working copy and to the repository, but
> >>>>> don't give it to anybody on 'cvs update' yet, until I latter commit the
> >>>>> addition". Do you propose exactly this? How could it be done without
> >>>>> write access to the repository?
> >>>>
> >>>> The semantics I want are to validate the addition of a new
> >>>> artifact. I frankly don't care if "cvs add" is implemented as you
> >>>> describe in that last paragraph or if it's implemented Greg's way.
> >>>
> >>> Maybe you don't care, but implementing a messy design will
> >>> eventually result in a mess for end-user. Then you will probably
> >>> care.
> >>
> >> The change to the CVS design really isn't significant. It can already
> >> contact the server, and it already implements server-side triggers.
> >> Adding a new one really has no significant impact to the quality of
> >> its implementation.
> >
> > Introducing yet another trigger will have significant impact to the
> > quality of implementation because it doesn't improve anything while
> > increases complexity.
> 
> You've admitted that you're not familiar with the CVS design. Please don't
> argue issues of complexity in a vacuum.

Yes, I'm not familiar with the CVS design, hopefully though it's not
that broken that introducing additional feature is less complex than
tuning an existing one to meet new requirements.

> >> And as I've demonstrated above, it actually improves the user model.
> >
> > No, you didn't demonstrate it, I'm afraid. No, it doesn't improve
> > anything compared to the ability to invoke commit-time triggers early,
> > or at least I still fail to see how it does.
> 
> Okay, here we go.  This is the status quo:
> 
> touch foo.h
> cvs add foo.h
> edit foo.h
> edit FOO.C
> compile FOO.C
> cvs commit
> -- Notifies user that "foo.h" does not meet naming conventions
> mv foo.h FOO.H
> edit FOO.H
> edit FOO.C
> compile FOO.c
> cvs commit
> -- Notifies the world that FOO.H and FOO.C were committed
> 
> Here's what happens if add-time triggers are used:
> 
> touch foo.h
> cvs add foo.h
> -- Notifies user that "foo.h" does not meet naming conventions.
> mv foo.h FOO.H
> cvs add FOO.H
> edit FOO.H
> edit FOO.C
> compile FOO.C
> cvs commit
> -- Notifies the world that FOO.H and FOO.C were committed
> 
> Congratulations, you've just made your change once, not twice.
> 
> Going the other way, and running commit-time triggers at add-time:
> 
> touch FOO.H
> cvs add FOO.H
> -- Notifies the world that FOO.H was committed
> edit FOO.H
> edit FOO.C
> compile FOO.C
> cvs commit
> -- Notifies the world that FOO.H and FOO.C were committed
> 
> And here's another, using a different commit-time trigger:
> 
> touch FOO.H
> cvs add FOO.H
> -- notifies the user that his RCS Id is invalid
> edit FOO.H
> cvs add FOO.H
> edit FOO.H
> edit FOO.C
> compile FOO.C
> cvs commit
>
> I hope this convinces you that appropriate checks should be made at
> appropriate times. Many commit-time checks are not appropriate to make
> at add time.

No, you didn't. Why? Because when I try to stay on your point of view
"the sooner user is notified about the problems, -- the better", I
immediately see that the example with your add-time triggers fails to
notify the user at add-time that his file doesn't contain valid RCS Id.

Having all the prerequisites the same, your example should be in fact
read: 

touch foo.h
cvs add foo.h
-- Notifies user that "foo.h" does not meet naming conventions.
mv foo.h FOO.H
cvs add FOO.H
edit FOO.H
edit FOO.C
compile FOO.C
cvs commit
-- Notifies the user that his RCS Id in FOO.H is invalid, commits(?) FOO.C
edit FOO.H
cvs commit
-- Notifies the world that FOO.H was committed

And with commit-time triggers run at add-time:

touch foo.h
cvs add foo.h
-- Notifies user that "foo.h" does not meet naming conventions and
-- doesn't contain valid RCS Id.
mv foo.h FOO.H
[cvs remove foo.h] # if cvs add only warns, not denies addition
edit FOO.H         # to add RCS Id
cvs add FOO.H
edit FOO.C
compile FOO.C
cvs commit 
-- Notifies the world that FOO.H and FOO.C was committed

BTW, the more triggers you implement, the more users will tend to use
the following model:

touch foo.h
edit foo.h
edit foo.c
compile foo.c
cvs add
-- Notifies user that "foo.h" does not meet naming conventions.
mv foo.h FOO.H
edit FOO.C
cvs add
cvs commit


[...]

> > You've just explained what I already understood. That's quibbling. Are
> > you going to answer to my direct question: how do I repeat the "run
> > add-time trigger" part? No way?
> 
> How do you run commit time triggers? If a commit failed, you retry the
> commit, right?

If I wish to check for commit to succeed I can do it as many times as I
like using 'cvs -n commit', right?

> If an add-time trigger fails, fix the error and retry the add. How
> simple is that?

The question is not what I do if add-time trigger fails, the question is
how do I repeat the checks later if it succeeded?

> > And here yet another question: what your add-time trigger does that
> > commit-time trigger can't do?
> 
> Answer:  Nothing.  It's just a matter of timing.  I argue that for certain
> classes of problems, postponing detection until commit time is too
> costly.

Run commit-time trigger at add-time.

> >>>> It would run the add-time triggers (for the first commit) and then the
> >>>> commit-time triggers.
> >>>
> >>> Will "cvs -n ci new_file" run the triggers in the design you have in
> >>> mind?
> >>
> >> It would do exactly what "cvs commit" would do without the -n
> >> option, except that it would not modify any persistent state in the
> >> repository or in the workspace.
> >
> > Great. Than why do you need separate beasts called add-time triggers? Run
> > commit-time ones as early as you wish instead.
> 
> Commit-time triggers check file content and create side-effects. These are
> not appropriate at add time.

"cvs -n commit" creates side effects? What '-n' is for then?

I believe the difference between commit-time and add-time is so subtle
that it should be left to the repository administrator to decide if the
checks to be performed at add-time and commit-time should differ. And
the default should be the same set of tests I still think.

[...]

> >> But I also recognize that, if you must work offline, it's better to
> >> have "cvs add" succeed in isolation than to fail (so that the user
> >> does not need to remember over a long period of time to add the file
> >> next time he connects). It's for this reason that the add-time trigger
> >> is optional when "cvs add" runs, but is mandatory at commit time.
> >
> > And that's one of problems with your proposed add-time triggers
> > solution. The user needs a way to invoke later the checks "cvs add"
> > didn't do in this case. That's the scenario where user needs separate
> > "add file to working copy" and "check file for validity against
> > repository" actions. Every time I ask you how do I repeat the add-time
> > check, you don't give satisfactory answer.
> 
> I'm not sure exactly what you want to hear. Add-time triggers run at
> the moment the user invokes "cvs add", unless the user opts out of the
> triggers. The add time triggers run a second time at commit time,
> before the commit-time triggers.

I want to know how do I invoke the checks that have been skipped during
off-line work when I go on-line?

> You as a user don't invoke triggers directly; they're invoked by CVS
> in a way that's not under your control. Re-read the manual with regard
> to commitinfo and loginfo. Commitinfo scripts run after the user
> enters a commit comment and before a new revision is created in the
> repository. If it fails, the user is notified. To re-run the
> commitinfo trigger, the user attempts another commit.

I, as user, don't care about commitinfo and loginfo scripts. As a user,
I only see the observable behavior of CVS commands. If I want to check
if my changes are going to be accepted by the repository, I invoke "cvs
-n commit", right? I can do it as many times as I wish with exactly the
same result unless my files or repository content/policies are changed,
right?

> Add-time triggers would work similarly. The scripts would be invoked
> by the "cvs add" command before the Entries file is edited. If it
> fails, the user is notified. To re-run the add-time trigger, the user
> attempts another add. But then there's the opt-out requirement, so the
> trigger can be defeated at the behest of the user.

So, similar to commit, when working off-line I should invoke "cvs -n
add" to be able later, when I go on-line, to invoke "cvs [-n] add" once
again to invoke the checks? But the whole purpose of invoking "cvs add"
is to add files to the working copy, so "cvs -n add" has no sense at all
when I'm working off-line.

> So the add-time triggers run a second time when the "cvs commit" command is
> invoked, before the commitinfo scripts run.  I would argue that they should
> run even before the commit message is edited.  If it fails, the user is
> notified.  To re-run the add-time trigger from this point, the user would
> attempt another commit.
> 
> > Besides, I still don't see why add-time triggers != commit-time
> > triggers. I.e., provided they are run on server, how they are different
> > from the point of view of the server?
> 
> They're not. Triggers are triggers are triggers, and they're all
> treated the same way by the server. It's just a question of which ones
> run in what order at what times.

So from the point of view of the server they run at different times? No,
I think they will be invoked by different server commands, right?

> If you're asking for implementation details, they'd probably be listed
> in a file similarly to commitinfo, and the fact that they're in this
> new file is what differentiates them from commit-time triggers.

For me it still seems that there is absolutely no need to have a
separate file invoked by separate server command, sorry.

> >>> Whatever the reasons for duplication are, the fact is that the server
> >>> must run add-time triggers when new file is being added to the
> >>> repository. Adding files to repository is what "cvs commit" does. Then
> >>> it's logical for "cvs -n commit" to run the triggers as well. Then,
> >>> provided you already have a way to run these add-time triggers through
> 
> >>> "cvs -n commit", why do you need yet another way to perform the same
> >>> operation (through "cvs add")? Thus, the duplication is not in fact
> >>> required, -- it's the wrong design choice you are advocating that leads
> >>> to the duplication.
> >>
> >> The reason to have "cvs add" do it is because it saves a step and
> >> makes a single action (from the user's point of view) whole. There
> >> should be no reason in the world why the user must invoke two commands
> >> to complete a single action, to add a file in this case.
> >
> > Ok, if I agree "cvs -n commit" is run as part of "cvs add", does it
> > eliminate this particular point of disagreement?
> 
> Nope.  :-(
> 
> Add-time triggers are a subset of commit-time triggers, and it's not
> appropriate to run all commit-time triggers at add time.

Why don't you allow triggers themselves decide if it's appropriate to
perform their checks accordingly to the action currently at hands? It
seems to be simpler from the point of view of server implementation and
more flexible.

[...]
> > Ah, now I see. I suggest "add new file to the working copy" to be a
> > useful user operation, and you believe it is not? So the minimum
> > semantics of "cvs add" you agree with is something like "add new file to
> > the working copy but only after you make sure the file path is OK with
> > respect to the repository".
> 
> YESSSSS!!!!
> 
> > Well, suppose you are designer and I'm a user then. I, the user, ask
> > you, the designer, to explain me why do you think I, the user, will
> > never need plain and simple "add new file to the working copy" user
> > operation.
> 
> The answer is: You can add anything you want to your workspace, but if
> you intend to commit it then you must comply with the design. And I
> will tell you at the moment you declare your intent if I think you're
> not in compliance.

Well, what is the command to just add the file to my working copy
without intent to commit it? Please don't tell me there is one as then
you agree that "add new file to the working copy" is a useful user
operation. Please don't tell me there is none as I need it indeed.

[...]
> > You still didn't provide any argument in favor of add-time triggers in
> > comparison with commit-time triggers invoking as part of 'cvs add', so I
> > still fail to see how add-time triggers could be a huge win to anybody.
> 
> I hope this message has cleared things up.

Yes, unfortunately it seems it cleared things up to the understanding
that there are no chances to get to a suitable agreement.

-- 
Sergei.