bug-cvs
[Top][All Lists]
Advanced

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

Re: CVS/Template files ... requesting opinion/clue


From: Mark D. Baushke
Subject: Re: CVS/Template files ... requesting opinion/clue
Date: Fri, 07 Mar 2003 10:04:54 -0800

Derek Robert Price <address@hidden> writes:

> Mark D. Baushke wrote:
> 
> Two things I'll probably get around ot after your commit if you don't
> feel like doing it before:   -s <serverapp> should probably imply -r,
> and search/replacing testcvs with clientcvs.  It looks like one less
> level of misdirection wouldn't hurt.

I agree that -s should imply -r, so my patch will do that. I will also
have -c imply -r as why would you need a client to be different than
just putting the path to the cvs under test as the argument.

It should be understood that the -s and -c switches will only make sense
with individual cases or ranges of cases as there have been some changes
that are bug fixes that impact the output of the various commands.

I think that replacing $testcvs and ${testcvs} with ${clientcvs} should
be considered as a separate patch. I am not sure it is the right thing
to do as using a ${clientcvs} implies client/server testing to me...

I will document the $clientcvs, $cmdargcvs and $servercvs variables I
have introduced as a part of this Template patch in the TESTS file.

> >I still don't know the right way to get the CVS/Template file updated in
> >place when the user commits a change to rcsinfo or any other files that
> >might have been included by rcsinfo during a database rebuild.
> >
> 
> I don't think there's an easy way to do this without an update.  As
> long as it works in client/server mode, I'm all for this being
> committed to the trunk.

Okay, I'll let someone else worry about this edge condition.

> The lack of consistent $keep exit points is because $keep is a fairly
> recent addition to the suite and nobody took the time to revamp the
> whole script.  The rule I've been using is that I add $keep anytime I
> work on a test if it isn't there already, to any new test, and any
> time I need it and it isn't there.

Would it make a bit more sense to do something like a shell function?

dokeep() 
{ 
    if ${keep}; then
      echo "Keeping ${TESTDIR} for test case \`${what}' and exiting due to 
--keep"
      exit 0
    fi
}

and then pass in ${TESTDIR} ? So, replace

          if $keep; then
            echo Keeping ${TESTDIR} and exiting due to --keep
            exit 0
          fi

with

          dokeep

which is a bit easier to add to all of the tests. Of course, the option
is really -k rather than --keep so perhaps the comment should change?

> If you're feeling motivated enough to put $keep exit points in all the
> tests, by all means feel free.  :)

I might do it if I have time, but I will do it as a separate cleanup
commit.
 
        Thanks,
        -- Mark




reply via email to

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