[Top][All Lists]
[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 14:58:23 -0400 (EDT) |
[ 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.
> 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".
> 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.
> > 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.
> 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>
- Re: Tag locking change, (continued)
- Re: Tag locking change, Larry Jones, 2002/10/08
- Re: Tag locking change, Paul Sander, 2002/10/08
- Re: Tag locking change, Greg A. Woods, 2002/10/08
- Re: Tag locking change, Paul Sander, 2002/10/08
- Re: Tag locking change, Greg A. Woods, 2002/10/09
- Re: Tag locking change, Mike Ayers, 2002/10/09
- Re: Tag locking change, Greg A. Woods, 2002/10/09
- Re: Tag locking change, Adam Bregenzer, 2002/10/09
- Re: Tag locking change, Greg A. Woods, 2002/10/09
- Re: Tag locking change, Adam Bregenzer, 2002/10/09
- Re: Tag locking change,
Greg A. Woods <=
- Re: Tag locking change, Adam Bregenzer, 2002/10/09
- Re: Tag locking change, Greg A. Woods, 2002/10/09
- Re: Tag locking change, Jenn Vesperman, 2002/10/09
- Re: Tag locking change, Jenn Vesperman, 2002/10/09
- Re: Tag locking change, Mike Ayers, 2002/10/09
- Re: Tag locking change, Larry Jones, 2002/10/09
- Re: Tag locking change, Greg A. Woods, 2002/10/09
- Re: Tag locking change, Paul Sander, 2002/10/09
- Re: Tag locking change, Greg A. Woods, 2002/10/09
- Re: Tag locking change, Paul Sander, 2002/10/09