Re: CVS diff and unknown files.

[Paul Sander]

On Jan 28, 2005, at 11:36 AM, address@hidden wrote:

> Todd Denniston <address@hidden> writes:
> > Sergei Organov 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.
> >
> > Careful, Last discussion time it was indicated that if add triggers 
> > were to
> > be added, then for them to be useful they would have to run at add 
> > time
> > (when the flag requesting them was passed) AND more importantly at 
> > commit
> > time, so commit on the server would if it had never seen the file 
> > before run
> > the add trigger and then the normal commit trigger.
> > So as long as the add trigger (script) had not changed between 'cvs 
> > add -c'
> > (IIRC that was the flag) and commit time and the trigger allowed the 
> > add,
> > then the server would at commit time
> > run the add trigger, get a pass
> > run any commit triggers, get a pass if appropriate.
> >
> > So in adding the add trigger functionality, the person patching CVS 
> > would
> > have to recognize the signals in the code indicating new 
> > file/directory at
> > commit, and connect the hook there too.
>
> 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.

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.

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.

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.

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

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.

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