info-cvs
[Top][All Lists]
Advanced

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

Re: Tag locking change


From: Greg A. Woods
Subject: Re: Tag locking change
Date: Wed, 9 Oct 2002 16:47:26 -0400 (EDT)

[ On , October 9, 2002 at 15:40:35 (-0400), Adam Bregenzer wrote: ]
> Subject: Re: Tag locking change
>
> On Wed, 2002-10-09 at 14:58, Greg A. Woods wrote:
> > 
> > My point was that you can do the same thing more reliably with a "cvs
> > update" in a working directory that is the DocumentRoot.
> 
> But then it wouldn't be automagic, it would be whenever cvs update is
> run.  Certianly every minute would be 'acceptable' but this solution is
> fine.  Plus in this case the repository and the live site have different
> directory structures.

There are many many many uncountable trivial and not so trivial ways to
make it "automagic" without having to simply run "cvs update" from cron
every minute.  Use a little imagination!

> > You could trigger the server-side "cvs update" in any number of ways,
> > though the very best would be if the individual doing the testing and
> > approving did it just before testing.
> 
> It's primarially for the developers, the testers only see it at
> regularly scheduled intervals so a developer's commit doesn't fsck
> something up.  The environment on the cvs server emulates the live
> environment, most developer machines do not that is the reason for the
> constant sync with cvs, immediate testing....

So?  Developers could trigger the "cvs update" of whatever test system's
DocumentRoot they use just as easily too!

>  Plus, I don't want to
> give testers access to the test server and I don't want to write an
> interface for them to do it.

That's no excuse and it doesn't strengthen your argument one bit.

> What if
> you don't want or need to have a working copy?

If you're doing testing like this then you _NEED_ to have a working
copy!  It's no different than doing baseline builds with "regular"
source code.

>  You cannot really do
> anything in cvs without a working copy, which is obviously something
> some people on this list have not realized.

Well, "Duh!"   :-)

>  The fact that what I said
> doesn't make sense is a reflection upon you of the design and
> methodology in cvs.  Ya know not everybody wants a working copy....

It doesn't matter what they "want".  They could want the moon, but they
can't have it.  This is the way CVS works, whether anyone likes it or
not!  :-)

There's nothing really special or limiting about CVS here either.  The
same kinds of rules must be followed for any kind of versioning tool
that manages multiple files "simultaneously".  It really just boils down
to fairly simple database theory.

-- 
                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>




reply via email to

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