[Top][All Lists]

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

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

From: Paul Sander
Subject: Re: 'cvs add' client/server semantics (was Re: Triggers)
Date: Sun, 6 Feb 2005 01:26:23 -0800

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.

reply via email to

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