Hi Guys, sorry for butting in but I couldn't resist trying to add my 0,02 EUR...
What I usually do in cases such as this, where there's a boundary between development and QA/approval, and where I am the admin, is this: Every development commit triggers an update of a separate working directory somewhere off the web server. After the update a deployment script is run which deploys the updated tree to the web server's document tree. During QA checking the working directory is locked to prevent any automatic updates (on the level of the auto-update script, not a CVS- level lock) so that everybody is quite clear on what it is exactly that QA is viewing. Then, if QA approves the working directory is tagged with an approval tag. Finally we do a CVS update to get all the commits that we missed while we were locked and the lock is removed so we have auto-updating after commits again. One of the things about this method is the decoupling of development and QA/testing CVS activity. To me, development and testing live in slightly different universes: development has different standards by which to measure the product than QA. So often you have development fixing bugs and implementing features at a slightly frantic pace whereas QA wants tighter control on what is tested when. So, another way of achieving that might be to have developers tag the tree whenever a bugfix or feature reaches stability, and QA update it's tree whenever a new tag is available. But that just means more work for everybody. Scripting can take away a lot of that work and tedium. Anyway, that's just my humble opinion. :) Erik --- Original mail from 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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
