Re: CVS diff and unknown files.

[Paul Sander]

On Jan 30, 2005, at 3:28 AM, address@hidden wrote:

> Paul Sander <address@hidden> writes:
> > On Jan 28, 2005, at 11:36 AM, address@hidden wrote:
> [...]
> > > If you consider my suggestion, there will be no such a beast as
> > > add-to-working-copy-time trigger. The commit trigger will notice the
> > > file is new and invoke appropriate additional actions (if any). 
> > > That's
> > > all. There is absolutely no need for separate 
> > > "add-to-working-copy-time"
> > > triggers. Clients still have ability to check if their new files 
> > > will be
> > > accepted by the repository using "cvs -n commit".
> >
> > What you suggest is exactly the status quo.  The problem is that the 
> > status
> > quo fails to meet the needs of part of the CVS community.  The reason 
> > is
> > because there's an underlying assumption that project policies are 
> > voluntary.
> > That assumption is false, and for good reason.
>
> It seems that you attempt to turn CVS itself into a project management
> tool. If that's your actual intention, please say it aloud, and I'll
> immediately stop all of my previous arguments and replace them with a
> single one: "CVS should not be turned into a project management tool".

Project management is not something that can be implemented in a single 
tool.  It encompasses a lot of things ranging from identifying a market 
all the way to end-of-life support.  Accomplishing it well involves a 
great many things, including planning and scheduling (the part that 
"project management tools" do), methodology (including policies, 
toolsets, and disciplines), and many other things, all of which must 
integrate and interoperate with each each other successfully.

I'm not asking for CVS to be a "project management tool" in any sense.  
What I'm asking for is a hook on which to hang other parts of project 
management.  The commitinfo hook already exists, and it's effective at 
what it does.  All I'm asking for is another hook, to be used as the 
project sees fit.

> > Where I work, our projects run for several years and have several
> > teams come in to do different things over its lifetime. (The company
> > maintains its market responsiveness by running multiple similar
> > projects concurrently, which allows several product releases per year.
> > I won't go into why this is the case, but suffice it to say that it
> > goes as fast as it goes and there's no speeding things up.) Over the
> > lifetime of the project, the number of files under source control
> > swells up well into the 6-figure range. To manage the complexity and
> > to assist the human factors of exploration, we live on certain
> > conventions. We have conventions for directory structure, conventions
> > for types of data that sit in what directories, and dozens of naming
> > conventions for files and directories. Our test suites have many
> > optional features, and different sets of these optional features are
> > required to run in different directories. Violations of the
> > conventions can cause the test suites to run incorrectly. Because no
> > errors are reported, there may be significant delays until the
> > problems are detected. At that time, the cost to repair the defects
> > may be huge, in the 6-figure range. And this doesn't consider the
> > humiliation felt by the poor guy who made the typo while creating the
> > file.
>
> IMHO in your case you shouldn't teach users to use CVS at all, -- you
> should teach them to use your project management tool, so they won't be
> aware about "cvs add" at all. If CVS lacks some functionality and that
> prevents you from building your tools on top of it, please provide some
> evidence this functionality is a must to achieve what you need.

Okay, CVS lacks an ability for "cvs add" to invoke a script, in the 
same manner that "cvs commit" invokes scripts via the commitinfo file, 
to validate the addition.

> > Therein lies the justification for add-time policy checking. Yes,
> > commit-time checking will still save many thousands of dollars in
> > repairs, but add-time policy checking saves even more.
>
> CVS doesn't prevent you from implementing whatever add-time checks you
> need on the client side. If you think otherwise, please provide an
> evidence.

See above.

> > And true, the projects I describe don't use CVS. But in the past at
> > another company that produced similar products using similar
> > processes, we did in fact use CVS, and we faced the same problems.
> > Most of the people in this forum don't seem to face these kinds of
> > problems to this extent, but anyone who does cross-platform
> > development faces similar problems.
>
> These problems are an issue of a good project management tool, not CVS.
> If you don't have suitable project management tools, it's not CVS
> problem. It would be CVS problem if it didn't provide enough
> functionality to allow you to build a suitable project management tool
> on top of it.

It doesn't see above.

> > > > If "cvs -n commit" runs the triggers to do your check(see my
> > > > question above), I have another question: in a remote server setup
> > > > (i.e., :pserver:, :ext:) which test was failed, the add or the
> > > > normal commit?
> > >
> > > With my approach there is no add-to-working-copy-time triggers,
> > > adding of a new file is normal commit (the commit time trigger
> > > should have a way to check if the file is already in the repository
> > > or not). So your question reduces to the following: "how client
> > > knows what exactly failed?" and the answer is "through appropriate
> > > error message, as usual".
> > >
> > > Please notice that with separate add-to-working-copy-time triggers 
> > > the
> > > situation at commit time is exactly the same as those triggers must 
> > > be
> > > run at commit time anyway. What's an answer to your question in this
> > > case?
> >
> > The answer lies not in the "if" the trigger runs, but "when". History
> > has shown that defects are easier, faster, and cheaper to fix when
> > detected early. Add-time triggers give the opportunity to detect
> > certain classes of defects very early. And by making them
> > non-voluntary (i.e. the user doesn't specifically request them), it
> > builds a process that enforces quality end-to-end.
>
> Please, enforcement of anything on the client side (in the working 
> copy)
> is not CVS business and shouldn't be. CVS doesn't prevent you from
> implementing whatever add-to-working-copy time checks you wish in your
> project management tool.

CVS can enforce policy with regard to changes made to the repository, 
as you know.  But there's a difference between touching a file in your 
workspace vs. doing "cvs add".  That difference is that "cvs add" 
declares an intent to modify the repository.  I argue that it is useful 
to see if the user's intended action is acceptable at the earliest 
possible time, rather than to wait and apply a bigger hammer at a time 
that's potentially awkward.

> > Many in this profession believe that the quality of products reflect
> > the quality of the processes that produce them. The observation is
> > that it's much harder to produce a high-quality product from a
> > low-quality process, and it's much harder to produce a low-quality
> > product from a high-quality process. That's not to say that certain
> > people can't buck the trend, but most of us don't.
>
> Nobody says anything against high-quality processes. But CVS is not
> everything, and it should do its own job with the highest possible
> quality. I'd suggest you to re-read the "What is CVS not?"
> <https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_1.html#SEC3> in 
> the
> CVS manual and then describe to yourself and to others what do you 
> think
> it should be. Lacking clean understanding of design goals and general
> agreement about them makes it useless to discuss implementation 
> details.

I've been using CVS since v1.2 (that was before the manual was 
written), so I'm pretty well aware of its limitations.  I also 
contributed code to it, so I have a pretty good idea of how it's 
implemented.  I've also gone back and read Grune's original scripts, so 
I have a pretty good idea of his design goals.  Can you say the same?

> For example, I believe that "CVS does not have change control" is in
> fact the most significant omission.

That is a significant omission, but it's much easier to build change 
control on top of CVS than it is to add policy enforcement.

--
Paul Sander       | "Lets stick to the new mistakes and get rid of the 
old
address@hidden | ones" -- William Brown