[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Dev & Production repositories?

From: Brian Kowald
Subject: RE: Dev & Production repositories?
Date: Wed, 14 May 2003 08:35:10 -0400

I think you are making it too complicated.

Have one repository.  This is where the code is stored.  Its definetly not
on the production server, but could be anywhere else.

Check out the newest code from the repository and work on it. This is the
Dev version. Test it until your happy with it.

Optional test department or QC:  Pull a clean version to the Dev server,
build and test it.  You don't have a guarantee that your build reflects
exactly whats in the repository unless do a clean checkout.

To go to production: Tag the version that will go to production.  Pull a
clean copy, build and
deploy to production.

Continue to work on the main truck of the repository for developement. You
always have the tag you can pull to get the latest production code.

Now suppose there is a bug in production.  To be able to make changes to the
production build, you have to create a branch. Create a branch from the tag
and you can make changes on that branch.  You have to checkout the branch.
Space providing, its sometime simplest to just check it out to a different
sandbox. If its a minor bug, just wait until the Dev version is stable and
deploy it.

To get changes from the production branch, back to the main truck you have
to MERGE. If its a minor change, you can just do it in two places. For
merging, you need to create merge point tags, so you only merge a change


-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf Of Kevin
Sent: Wednesday, May 14, 2003 12:26 AM
To: address@hidden
Subject: Dev & Production repositories?

Hello everyone,

I'm a CVS newbie, but learning fast.  I need some help with determining
the best way to go about setting up CVS for my project.

First, I have two physical servers (dev and production).  I'm currently
making changes to files on my dev server and then ftp'ing them to my
production server.  I need version control badly as files are getting
over written, etc.

I'd like to be able to checkout the dev module and make changes, then
test them (which if I understand correctly takes a commit before the
changes are uploaded to the repository) on the dev server, then if all
goes well, have the appropriate files committed to the production
server.  Keep in mind that there would be two repositories each on
different servers. I've seen the project CVSviaFTP, but don't want
things to be committed to production until it's been tested in dev and
explicitly flagged to be committed to production.  I've heard this setup
is complicated.

Another way I've heard about is to make a module on the production
repository, then create a branch for dev.  I could use the loginfo
script below to update stuff based on where it was checkedout....

^foundation     (date; cat; (sleep 1; cd
/var/lib/interchange/foundation_dev; \
cvs -q up -d; cd /var/lib/interchange/foundation; cvs -q up -d) &) \
 >> $CVSROOT/CVSROOT/updatelog 2>&1
ALL     /usr/bin/cvs-log     $CVSROOT/CVSROOT/commitlog $USER "%{sVv}"

Maybe I'm just confused with it all.  I've read the documentation at
but haven't found a source that shows me how to layout my environment for
staging, production or dev/production.

Any help is appreciated!

Kevin Old <address@hidden>

Info-cvs mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]