Forum OpenACS Q&A: Running dev/staging/prod servers off of CVS sources

1: Running dev/staging/prod servers off of CVS sources

Posted by Ola Hansson on 01/29/01 02:45 PM

After having read both of the ASJ articles on CVS at aD (http://www.arsdigita.com/asj/version-control/ and http://www.arsdigita.com/asj/cvs) I decided to try to do things right and give cvs a shot.

Ron's article gives an example where he imports ACS source code from a tarball into the repository. What I want though is to checkout the latest code from SourceForge or OpenACS.org (think I know how to do that 😉 to work on that and update the checked-out staging and production servers after having updated the code from (say) SourceForge.

Questions:

I can't update my own repository by updating from an external repository at, eg., SF now can I?

Do I have to import the whole source again when ACS version is out?

I feel confused (to underestimate) when it comes to choosing a good aproach and if anyone understands what I'm trying to say I would very much appreciate your help!

TIA

2: Response to Running dev/staging/prod servers off of CVS sources (response to 1)

Posted by Cynthia Kiser on 01/30/01 05:07 PM

No you cannot directly update your repostitory from the external repostiory. You need to do vendor imports from your SorceForge checkouts. This is just as suggested in the version control article but in step 2 of the "Setting up a new project under CVS" section instead of getting a new tarball, do a new checkout from SourceForge. Then continue with the vendor import into your projects's CVS repostitory.

The package system in OpenACS 4.0 should help you not have to import more code than you want. For update releases of the current OpenACS I would do vendor imports of the full source code - but realize that you will only get the diff stored in your CVS repository so you are not storing full versions of multiple tarballs.

3: Response to Running dev/staging/prod servers off of CVS sources (response to 1)

Posted by Ola Hansson on 01/31/01 12:05 AM

Thanks for your answer Cynthia,

One possibly possible solution that I came up with is to do a brand new checkout from SF and then do a vendor import to my project's repository (as you too suggest) followed by checkouts of developement, staging and production code.

After that, whenever there's been any substancial additions to the code over at SF, I was thinking I could update my dev code area from the SF repository and subsequentally merge the changes back to my repository...And of course update the staging and prod servers thereafter.
However I can't stand the thought of trying this theory of mine out so I gess I will stick to your suggestion😊 Thanks!

4: Response to Running dev/staging/prod servers off of CVS sources (response to 1)

Posted by Ola Hansson on 01/31/01 12:34 AM

BTW, the two cvs-articles contradict each other slightly. Both Phil and Ron agree on that there need only be two databases (foobar and foobar-dev, eg.) but, while Phil talks about letting the production site have it's own db and share a db for developement/staging, Ron on the other hand speaks of a shared prod/staging db and a separate dev db...

Whitch is it?

Maybe I should ask Ron about this though maybe it's not all that important.

Cheers.

5: Response to Running dev/staging/prod servers off of CVS sources (response to 1)

Posted by Cynthia Kiser on 02/02/01 10:27 PM

The difference in which database to run your staging server against is a matter of what degree of changing of the data you will want/need to do during the staging tests. For many sites that have lots of content that you want to see how the display changes you are making will look it makes sense to run the staging server off the production database - but then you need to be careful about altering the data since it will change your "real" copy. The project I work on is all about changing data and making sure that those changes are displayed properly throughout the various views of that data (different customers, customer service, and site admin views) so we want to be able to really mess with the data durint testing. So my staging server runs off my developement database.