Re: CVS diff and unknown files.

[Paul Sander]

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.
>
> 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.

> 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.  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.  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.

> > 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.

> 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.

> > > > > > Another point that I would like to make, however, is that CVS can
> > > > > > become more feature-rich, support multiple policies, and have a
> > > > > > simpler user interface (in most use cases, at least) all at the 
> > > > > > same
> > > > > > time. The problem is that most of us here are too close to the
> > > > > > implementation to take a fresh view of the problem.
> > > > > >
> > > > > > > In the core CVS program the "cvs add" and "cvs remove" operations
> > > > > > > must be fixed to be equivalent to "vi file.c" -- i.e. operations
> > > > > > > which _ONLY_ affect the local working directory and which _NEVER_
> > > > > > > contact the server.
> > > > > >
> > > > > > See above. If there are no add-time triggers, then I can live with
> > > > > > what you say. On the other hand, some shops REQUIRE add-time 
> > > > > > triggers,
> > > > > > and if add-time triggers are used then contacting the server is
> > > > > > REQUIRED to make them run.
> > > > >
> > > > > Sorry, add-time with respect to what? Add-time w.r.t. to working 
> > > > > copy is
> > > > > entirely different from the add-time w.r.t. repository. Do you 
> > > > > realize
> > > > > currently there is no command but 'cvs ci' meaning "add this file 
> > > > > to the
> > > > > repository"? Add time w.r.t. repository currently happens when you 
> > > > > 'cvs
> > > > > commit' the new file. Do you propose to change this?
> > > >
> > > > What I mean by "add-time" is the moment in which the user invokes
> > > > the "cvs add" command. The canonical example of such a trigger is
> > > > one that enforces naming conventions, but there are other reasons
> > > > to control what the user can add. (Some shops don't want users
> > > > creating directories, for example, and require the CM team to do it
> > > > for them.)
> > >
> > > So, provided that "cvs add" adds the file to the working copy, your
> > > definition means "add-time to working copy". Requiring server 
> > > triggers
> > > to be run at add-time to working copy seems rather strange design 
> > > choice
> > > in my opinion.
> >
> > 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.)

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.

> 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.  If users 
think the wrappers are in their way, they'll drop down to CVS to add 
the file, causing more significant breakage later.  It's at that time 
that they finally learn the value of the process.

> > > > When "cvs add" runs, I don't care whether or not the CVS server
> > > > modifies the repository. Some people seem to think that running "cvs
> > > > add" while disconnected is a useful thing to do. (I take the 
> > > > attitude
> > > > that client/server applications shouldn't be expected to run 
> > > > without a
> > > > working network, so I'd never run any CVS command when I was unable 
> > > > to
> > > > connect to the server.)
> > >
> > > Very strange attitude. And a very unusual definition of expectations
> > > associated with client/server applications. Having this definition, 
> > > mail
> > > client isn't supposed to let you do anything with the mail on your
> > > computer without a working network?!
> >
> > I rely heavily on IMAP and SMTP for mail transport.  At work, my mail 
> > client
> > lives on an NFS server.  So no, I don't expect mail to work when the 
> > network
> > is down.
> >
> > 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.

> > 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".

> > > > However, since triggers enforce policy and must not be defeatable,
> > > > e.g. by changing one's path or bypassing a wrapper or hacking the
> > > > client machine, they're best implemented as a server feature. It's 
> > > > for
> > > > that reason, assuming add-time triggers are implemented, they 
> > > > require
> > > > a connection to the server.
> > >
> > > The "add-time triggers" you are advocating would then create an
> > > unfortunate precedent of preventing user from modifying his working 
> > > copy
> > > at a will of CVS repository administrator! PLEASE, DON'T DO IT TO 
> > > CVS!
> > > Sorry for shouting. Fortunately, as triggers are run on the server,
> > > there is in fact no way to actually impose any policy on the client
> > > side.
> >
> > The CVS administrator guards what enters the repository. Users
> > typically don't do things that they know will be refused by the
> > repository; it's a waste of time and effort. The add-time triggers
> > simply bring to the attention of the users earlier in the cycle that
> > their code will be refused later anyway.
>
> 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.

> > What I'm seeing is a knee-jerk reaction of "ooooh, he wants to limit
> > what I can do in my own workspace!"
>
> Don't you?

Well, yes and no.  I'm only preventing you from adding things that 
can't be committed anyway.

> > or "he wants to change the behavior of a command that I use!".
>
> Backward incompatible changes are usually wrong idea. You need really
> firm arguments to make it happen. Fortunately for you, current "cvs 
> add"
> does contact the server, so that's not an argument against your
> proposals.

My requirement is not that "cvs add" contact the server.  My 
requirement is that "cvs add" have the ability to enforce policy.  (So 
yes, I do have a secondary requirement that "cvs add" contact the 
server for the purpose of running the add-time trigger, but the user 
opts out of that check then there's no need to contact the server.)

As for the backward compatibility argument, here's another one:  How 
long does a bug have to exist before it becomes a feature?  By the time 
the bug is fixed, there are so many workarounds in place that the users 
actually come to depend on the bug's behavior.

But the truth is that add-time triggers are not any more 
backward-incompatible than the addition of any other feature.  If it's 
not used (i.e., the add-time trigger mechanism, call it "addinfo", is 
implemented, but no actual triggers are registered) then there's no 
impact on the user.

If Greg's proposal to isolate "cvs add" from the server is implemented, 
then implementing add-time triggers will have an effect until the user 
opts out of the add-time check.

> > 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?

> > 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.

> > 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.

> > > > > 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.

> > > > For example, suppose a mixed Windows/Unix shop requires all files to
> > > > have upper-case 8.3 file names. A new programmer splits a header 
> > > > file
> > > > and creates a new foo.h. He adds the file, then proceeds to modify 
> > > > all
> > > > of the source files to include the new foo.h. Then he updates all of
> > > > the dependencies in his makefiles. He builds and tests on Unix. He
> > > > types "cvs commit", types a very detailed log of his actions, and
> > > > finally punches the screen. This person might have saved a day's 
> > > > work,
> > > > his equipment, and his knuckles if only "cvs add" had said "Sorry,
> > > > this new file violates our naming policy, try renaming it to FOO.H
> > > > instead."
> > >
> > > ... and what? Is the file added to the working copy or not? If not, 
> > > then
> > > if I've specified a few files, are they all not added, or only those
> > > that didn't pass the test? Still I'm opposed to the idea that "cvs 
> > > add"
> > > would refrain from adding files to the working copy. It's not 
> > > repository
> > > administrator business to decide what I can and what I can't do to my
> > > working copy. If "cvs add" will only warn about the problems, -- 
> > > that's
> > > OK with me as a user.
> >
> > 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?  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.

> > 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.

> > > 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, and running 
commit-time triggers at add-time is not appropriate.  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.

> > > > > 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.

> > 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 matter which method records the new file, the client must still
> > > > contact the server to run the add-time trigger.
> > >
> > > Sure, the only difference is that you require add-to-repository 
> > > trigger
> > > to be run at add-time-to-working-copy time as well, and that's IMHO a
> > > wrong design decision.
> >
> > Okay, use the option to disable the add-time trigger.
>
> Thanks, I will, though is still don't see why do you call the trigger
> "add-to-working-copy-time" if it's in fact "add-to-repository-time"
> trigger just happened to be invoked as a part of "cvs add" command, and
> the latter trigger already has its name, the 
> "commit-to-repository-time"
> trigger.

It is in fact an "add-to-working-copy-time" trigger.  The "cvs add" 
command shouldn't modify persistent state in the repository.  But it 
should warn the user if he's adding something that it knows will 
ultimately be rejected by a subsequent commit.

> > Or, don't use add-time triggers at all.
>
> Sorry, as a user, I can't if repository administrator uses them.

If the administrator has installed them, then it was done for a reason. 
 And you don't have a choice but to use them at some point before the 
first commit after the add.  Get over it.

> > > > > > I had hoped that this was clear in the last go-round, but 
> > > > > > apparently
> > > > > > not.
> > > > >
> > > > > For me it is not, sorry. Let me give yet another example. Suppose 
> > > > > I've
> > > > > created a new_file today and have checked it's ok using proposed 
> > > > > 'cvs
> > > > > add -c new_file' command. Two days later what I've checked could 
> > > > > already
> > > > > be wrong (policy change, another user added the same file, etc.). 
> > > > > So
> > > > > there are two questions:
> > > > >
> > > > > 1. How do I repeat my check later? By just repeating 'cvs add -c
> > > > >    new_file'? This would produce warnings "new_file has already 
> > > > > been
> > > > >    added" that is not a good thing for an operation intended to 
> > > > > make
> > > > >    checks, I'm afraid.
> > > > >
> > > > > 2. Should 'cvs -n ci new_file' run the same triggers 'cvs add -c
> > > > >    new_file' runs? If exactly the same, then why the duplication?
> > > >
> > > > My vision is that the user would run "cvs ci new_file" without the 
> > > > -n
> > > > option.
> > >
> > > If this is supposed to be an answer to my first question, then it is 
> > > not
> > > in fact an acceptable answer. I asked "how do I repeat the check?" 
> > > and
> > > you've answered "by committing your changes to the repository". 
> > > Should I
> > > take it as "no, you will have no easy way to repeat the check later"?
> >
> > Okay, here's a different tack:  *You* don't perform the check.  CVS 
> > performs
> > the check on your behalf.  When you run the  "cvs add" command, what 
> > would
> > happen below the covers is this:
> >
> > Run add-time trigger
> > If trigger succeeds, create entry in Entries file
> >
> > When you invoke "cvs commit" at a later time, CVS performs the
> > following steps:
> >
> > Run add-time trigger
> > If add-time trigger succeeds, run commit-time trigger
> > If both triggers succeed, create new version in repository and update
> > Entries
>
> 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 an add-time trigger fails, fix the error and retry 
the add.  How simple is that?

> 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.

> > > > 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.

> > > > The reason for the duplication is partly to catch possible changes 
> > > > in
> > > > policy between add-time and commit-time, and partly to avoid abuses 
> > > > by
> > > > those who unplug their computers as part of their procedure to add 
> > > > new
> > > > files (which includes those who insist that running "cvs add" while
> > > > disconnected is a reasonable thing to do).
> > >
> > > Running "cvs add" is indeed reasonable thing to do no matter if
> > > connected or not. When I'm sitting on another end of our planet from 
> > > the
> > > server running the repository I don't wish to depend on the 
> > > existence of
> > > the link between my computer and the server when I decide the file
> > > should be added to the project. The more I can do offline, -- the
> > > better, -- ability to do things independently is one of the 
> > > properties
> > > of distributed systems that make them superior in many cases.
> >
> > Well, there's also the founding philosophy of the whole client/server
> > revolution, which is that data islands are bad.
>
> Excuse me my ignorance, but what's client/server revolution? When did 
> it
> happen?

It happened roughly in 1985-1992, right after DNS was standardized, and 
the stability of the Internet protocols was proven in BSD 4.2.  Prior 
to that time, the rule of the day was to build monolithic applications 
on mainframes connected to the users via dumb terminals.

> > 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.

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.

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 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.  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.

> > > 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.

> > > > > > > Policy goes above -- it is not hard-coded in the core
> > > > > > > functionality.
> > > > > >
> > > > > > Agreed. But the tool must be sufficiently flexible to allow
> > > > > > robust implementations of policies. Sometimes triggers are the
> > > > > > right way (and wrapper scripts are not), and we've identified one
> > > > > > area here where CVS is not sufficiently flexible.
> > > > >
> > > > > That's why I insist CVS should have sane set of elementary
> > > > > operations that could be then combined in different ways. I have
> > > > > no objection against "compound" CVS commands that do multiple
> > > > > things (preferably making them atomic), but existing of
> > > > > corresponding elementary commands is a must, I believe. Designing
> > > > > tools in a different manner results in a lack of flexibility, or
> > > > > at least my experience suggests it does.
> > > >
> > > > Indeed. To me, the ideal implementation would be a collection of
> > > > very primitive operations glued together by a scripting language,
> > > > and have the command line interface invoke scripts.
> > >
> > > ... and then you suggest "cvs add" semantics that instead of doing
> > > one thing, adding files to the working copy, will in fact do two
> > > things, -- adding files to the working copy and checking if the
> > > commitment of these files later would be OK. It seems you finally
> > > contradict to your own goals, sorry.
> >
> > Not a bit. Logical primitives and user operations are two different
> > things. Creating a new revision in the repository is a logical
> > primitive. Invoking a trigger is logical primitive. Updating the
> > Entries file is a logical primitive. The "cvs commit" command is a
> > user operation that does all of these things. There's a big difference
> > in these concepts, and I think that they should be kept separated. And
> > I don't think that every logical primitive should necessarily be
> > exposed to the user, though APIs to logical primitives are useful in
> > building new user operations.
>
> 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.

> > > > I don't believe that the existing CVS command line offers enough
> > > > flexibility, in a number of ways. And an implementation like the 
> > > > one I
> > > > describe here cannot be built without trashing most of the existing
> > > > code. But that's a different discussion...
> > >
> > > If what you have in mind will trash most of the existing code, then
> > > it's obviously better to take a fresh start and design the tools from
> > > scratch. But that won't be the CVS anymore, I'm afraid.
> >
> > Yeah, and I'm not recommending (at this time) that CVS be rewritten as
> > a library with an embedded scripting language. I'm just recommending
> > that add-time triggers be added. The latter is easy, it's a huge win
> > for those who need it, and has zero impact on those who don't.
>
> 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.

--
Paul Sander       | "To do two things at once is to do neither"
address@hidden | Publilius Syrus, Roman philosopher, 100 B.C.