Re: Tag locking change

[Adam Bregenzer]

On Wed, 2002-10-09 at 14:58, Greg A. Woods wrote:
> [ On , October 9, 2002 at 14:26:15 (-0400), Adam Bregenzer wrote: ]
> > Subject: Re: Tag locking change
> >
> > On Wed, 2002-10-09 at 13:58, Greg A. Woods wrote:
> > > 
> > > Yes, sure, but that copying is done (or at least the source for the
> > > copying is created with) "cvs update", RIGHT?  (i.e. it had better be!)
> > 
> > Not at all.  The server that holds the cvs repository also has apache
> > runing on it.  When a commit occurs each file that is committed is
> > copied into a seperate directory.  That directory is the DocumentRoot
> > for apache.  That way, when a change is committed it is automagicall
> > viewable by browsing to the cvs server.  The point is that one who does
> > not edit the site manages and approves the site.
> 
> 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.

> 
> >  Currently that
> > individual runs cvs rtag when the site is in a producation ready state. 
> 
> Then that individual _could_ edit the site, so it is irrelevant from the
> access rights point of view whether or not that indivudual runs "cvs
> tag" or "cvs rtag".
He/she certianly *could* but do you want a manager knowing they can? :P
Plus, she doesn't modify the code so why keep or have a checked out
copy?  (I understand it's necessary in cvs, I'm trying to make a point)

> 
> > Then a script is run that does a cvs export with that tag and posts it
> > to the live site.  It has nothing to do with the client, it's all
> > *server* side.  I see no reason for it to bve tied to an update, I don't
> > even know how to execute a server-side script on update and wouldn't
> > want to anyways.
> 
> 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....  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.

> 
> > > When it's "ready" you should be "cvs tag"ing the working directory which
> > > matches the "ready" revisions of the files.
> > 
> > But what if I have not working directory.  What if the developers are
> > just that.  Developers.  I can certianly tell them to tag it for me but
> > that's a bit strange.
> 
> That does not make any sense.  You can have a working directory if you want.
Well, the first sentence should be 'But what if I don't have a working
directory', but I think you mean my point doesn't make sense.  What if
you don't want or need to have a working copy?  You cannot really do
anything in cvs without a working copy, which is obviously something
some people on this list have not realized.  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....

> 
> > Actually, I realized something else, you can't run an rtag from a
> > application that was run from a commitinfo script.  That's what I was
> > thinking.
> 
> You can't run "cvs tag" directly from comitinfo scripts either, but that
> shouldn't be an issue.  It's easy enough to design better solutions.
> 
> 
> -- 
>                                                               Greg A. Woods
> 
> +1 416 218-0098;            <address@hidden>;           <address@hidden>
> Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>