Hi, A pragmatic way to do it is to do put updates on the server using:
cvs co -rRELEASE_20 proj Then, ... To make a quick fix, get the latest source code on your dev environment, bump up the version number in your dev environment (even on your local machine running apache/iis/whatever). Tag it using cvs rtag, then do an rdiff to examine changes. Go through any change procedure (which for a single textbox caption should not be too onerous). Then, update the production server using: cvs up -rRELEASE_21 It shouldn't be too hard. The key is to make sure there is an easy place to edit the site in a dev environment. So, for a start -- don't version control the database config files or you'll have pain where prod and dev are fighting over which database connection to use. People can then go up and fiddle with the labels in 5 seconds -- but it doesn't show up to customers until you hit the big button. If you make it easy for people they shouldn't complain. You definitely want a release controlled environment, but at the same time, a system which involves lots of work just to change a single line of code is problematic and needs to be automated at some level (the grunt work, not the decisions, that is). Another thing -- don't be shy about creating versions: there's no problem with making several hundred versions which include nothing more than minor fixes to things here and there. Given that, no prob in making a script which fetches all tags, gets the highest release number, tags the next increment, and spits out a diff and patchset onto the desktop. People will love you for it. :) My 5 new/250 old francs, Cheers, Matthew Herrmann --------------- Far Edge Pty Ltd http://www.faredge.com.au/ Level 6, 35 Chandos Street St Leonards 2065 Ph: +612 8425 1400 -----Original Message----- bobby temper wrote: > > Hello, > > Thanks for the answers. > > I also agree with Jim, but it might be hard to convince content people that > they have to go throught a staging first, for simple stuff. I will definitly > do whatever i can, tho :). > > Todd, what you're saying refers actually to what i'm asking: the production > code is a checked out copy? (with the cvs folders, etc...). We already have > a tag/branch procedure. The problem is, as now, we have a "cvs export" copy > on production (and no cvs client on production either...). I'm wondering if > it would be better to install a cvs client, and have the code being a "cvs > checkout" copy. That way, we could do like you're proposing, with cvs diff. > I'm actually just wondering if doing it that way has some drawbacks, vs > doing a "cvs export/tar-gzip/scp" procedure. OUCH. OK, I am sometimes considered an SOB by those that work with me when it comes to releases, but it sounds like it is time for 1) the production machine to have the number of user names reduced to root+otherinstalleddefaultusers & projectadmin or 2) the production area locked down so only root & project admin can make modifications. If I was the person who had to answer "what is in the production machine today?", I would make three documents document 1) I, [my name], have permission to [insert lock down method] the production [machine|area], and anyone who subverts that gets [insert appropriate punishment]. This will be implementing an industry best practice [site sources (besides/in addition to Jim & me)][1] ________boss_signature_here____Date. document 2) I, [my name], am not responsible for the content of the production machine even though it has been suggested to customers we have someone in that job. ________boss_signature_here____Date. document 3) I, [my name], have informed [boss's name] that the production [machine|area], is out of control, and anyone with [insert level of access] can modify it at will and the changes will not be recorded in version control, so we can not track who or when a change was made. I, [my name], have informed [boss's name] of the following method for correcting the situation and been denied. [insert method(s) here] ________boss_signature_here____Date. I would then take them to my boss, and indicate s/he should pick one and sign it. BTW I am camping as physically close to my boss's person as is possible during working hours until one is signed. :) 1 gets you the ability to fix the problem. 2 indicates it should not be your butt that is the one to kick if there is a problem with what is on the production machine/area. 3 indicates the boss's butt is the one to kick _if/WHEN_ there is a problem with what is on the production machine/area. If the boss refuses to sign any of them... 1) email the concerns and fixes to the boss, and print a copy. 2) keep a note book recording the documents, the email & when they were presented. 3) consider if it is worth going to the boss's boss with the notebook. Sometimes you just have to drop back to these kind of strong arm tactics to get what is needed, and keep your own head. if the boss picks #1 (this is what you hope for), you can implement the corrective change ... tell the complaining people "the boss indicated it should be done", and (to relieve some of the stress you just applied to his/her arm) tell the boss to tell them "we are implementing industry best practices...(pause to see if they complain more, if so finish with) you will work with it. If you do not feel it is best practice, document why, and site your sources." before they show up in the bosses office. > > Regards, > Bobby > <SNIP> [1] you could start by searching the mailing list for other people dealing with release management http://www.cmcrossroads.com/bradapp/acme/ http://www.cmcrossroads.com/bradapp/acme/#BuildRepro http://www.cmcrossroads.com/bradapp/acme/repro/SoftwareReconstruction.html http://lists.gnu.org/pipermail/info-cvs http://www.google.com/search?hl=en&q=release+managment&btnG=Google+Search http://www.google.com/search?hl=en&lr=&q=%22release+managment%22+CVS&btnG=Se arch http://www.google.com/search?hl=en&lr=&q=%22release+management%22&btnG=Searc h http://www.google.com/search?hl=en&lr=&q=%22release+management%22+CVS&btnG=S earch http://www.google.com/search?hl=en&lr=&q=%22release+management%22+%22best+pr actices%22&btnG=Search http://www.google.com/search?hl=en&lr=&q=%22release+management%22+%22best+pr actices%22+cvs+-pvcs&btnG=Search http://www.w3.org/OOP/9606_Workshop/submissions/31-W3COMG.html http://www.wipro.com/prodesign/focusareas/complatforms/complatpcasestudy8.ht m you get the picture right? -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
