Re: 'cvs add' client/server semantics (was Re: Triggers)

[Paul Sander]

On Feb 5, 2005, at 12:47 PM, address@hidden wrote:

> [ On Thursday, February 3, 2005 at 00:29:31 (-0800), Paul Sander 
> wrote: ]
> > Subject: Re: 'cvs add' client/server semantics (was Re: Triggers)
> >
> >
> > Many shops seem to think that it's reasonable to allow users to commit
> > code only after it has successfully compiled.
>
> In fact I happen to agree with that partciular policy and I try to
> follow it as well as I can even on my private projects.
>
> However just because a new file appears doesn't mean it's immediately
> going to be used in the build -- quite the opposite as it normally
> won't, at least not with any sane build system I would use.
>
> I.e. your argument about not immediately committing new, but probably
> still empty, files is, still, a complete and total straw man.
>
> Please try to think a little about these things.  Your answer was the
> kind of automaton-like regurgitation of a simplistic rule which I would
> only have expected from a computer following an ill-conceived and
> overly-strict recipe -- or maybe a manager who doesn't actually know 
> how
> to do the job himself. :-)

Some shops rely heavily on autodiscovery in their build systems, and 
consider it feature.  Some shops don't permit committing dead files to 
an active source base, either, whether it be because they're brand new 
or because their APIs have just been disconnected from the rest of the 
system.

Please try to open up to disciplines that you have not directly 
experienced yourself.  And you need to start to acknowledge that these 
are viable approaches to certain problems, even if they're not the 
specific ones you would choose.  Right or wrong, good or bad, these are 
real world experiences.

> > Perhaps, but I want the option to ask it if it foresees any problems
> > with my actions.  If you don't like it, don't use it.
>
> I didn't say you couldn't have such an "option" -- in fact you already
> have it, in spades.

Okay, let me be more clear:  I want the "cvs add" command to give me 
the option.  There's a reason why it needs to be there, even if you 
refuse to acknowledge it.

> There are an almost infinite number of ways for you to ask if a new
> filename is acceptable and not one of them requires any change of any
> kind to the core CVS program.

And most of them require much more work to work around the absence of 
the capability in CVS than to implement it directly.

> Many of those possible ways don't even require software 
> implementations.
>
> CVS is not a substitute for management, nor a substitute for developer
> communication, nor does it have a built-in process model.  And these 
> are
> all good things for it not to have too!

I agree that CVS shouldn't have this stuff hard-coded into it.  
However, it's crucial that it have the necessary hooks to integrate 
with the tools that perform those functions.  This is one of the 
reasons why I maintain that CVS remains a toy system, suitable for 
managing toy or immature development efforts.

> If your project requires strict file naming rules be followed then you
> need to invent procedures and processes to help meet that requirement
> but you should not even expect to look to CVS for help here.  The very
> fact that you do suggests you think CVS is, or should be, something 
> that
> it is not.
>
> That said you can in fact still implement technical controls that can
> mandate a requirement like strict file naming rules, IFF you do it
> through commitinfo scripting hooks.  If that's not sufficient for your
> needs then CVS is not the right tool for (this part of) your project.

After two weeks are arguing, you still don't get that the very best 
time to check a file's name is at the moment it's created.  Sigh.  Your 
loss.

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