Re: Personal development CVS question

[Jonathan Chen]

On Mon, Mar 24, 2003 at 12:04:42PM -0500, Steve Bertrand wrote:

[...]
 Am I correct with this method?:
 
 - commit my current source and branch as RELEASE
 - download RELEASE onto production server and put into use
 
 - further work will continue normally, and the RELEASE branch will not be
 affected
 
 - when I am ready for the new features, I can re-branch to a new RELEASE,
 redownload onto production and repeat
 
 - if changes are made and required into RELEASE, I can merge at that time.

You described pretty much the standard practice.

Cheers.
-- 
Jonathan Chen [EMAIL PROTECTED]
--
 A person should be able to do a small bit of everything,
specialisation is for insects

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message

Re: Personal development CVS question

[Garance A Drosihn]

At 12:04 PM -0500 3/24/03, Steve Bertrand wrote:
The current state of my app is ready for production, so I would
like to take a snapshot of it as is, then implement it. I would
like to leave this snapshot alone, and further develop in other
aspects of the program now. Am I correct with this method?:
- commit my current source and branch as RELEASE
- download RELEASE onto production server and put into use
- further work will continue normally, and the RELEASE branch
  will not be affected
- when I am ready for the new features, I can re-branch to a
  new RELEASE, redownload onto production and repeat
You generally want to use a special name for the release branch,
such as RELEASE_1.  When you later want to make a new release,
you name that branch RELEASE_2.  You may still want to work off
the RELEASE_1 branch even though RELEASE_2 has been made.
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message

Re: Personal development CVS question

[Giorgos Keramidas]

On 2003-03-24 12:04, Steve Bertrand [EMAIL PROTECTED] wrote:
 I have developed a project for use at my ISP, which I have been keeping in
 my CVS repository (as I do all of my projects). CVS is working great, but
 I have a somewhat unrelated question, which I would apprecieate
 redirection if required.

 The current state of my app is ready for production, so I would like to
 take a snapshot of it as is, then implement it. I would like to leave this
 snapshot alone, and further develop in other aspects of the program now.
 Am I correct with this method?:

 - commit my current source and branch as RELEASE

A tag with RELEASE_1_0 is all you need to be able to extract the
versions of the files as they were at the date of the tagging
(i.e. just before the RELEASE goes out).

A branch is only required if you want to continue development in two,
uhm, `branches'.  The HEAD of every file tracks the latest, most
cutting-edge, bleeding from all edges, version of the file.  The
branch of the release, on the other hand, is only touched when changes
are backported from your experimental, HEAD branch to the release.

 - download RELEASE onto production server and put into use

 - further work will continue normally, and the RELEASE branch will
 not be affected

True.  You have to commit stuff to the release branch to affect it.

 - when I am ready for the new features, I can re-branch to a new
 RELEASE, redownload onto production and repeat

Sounds like a good plan to me.

 - if changes are made and required into RELEASE, I can merge at that
 time.

Yep.  If you create a separate branch for the release version, for
instance with:

$ cvs checkout project
$ cd project
$ cvs tag -r RELEASE_1_0_0_BP

(where _BP means branch point and is a tag, not a branch), then you
can use:

$ cvs checkout -r RELEASE_1_0_0_BP project
$ cd project
$ cvs tag -b RELEASE_1

After this point, you have a RELEASE_1 branch that you can use to make
changes to the 'stable' branch:

$ cvs checkout -r RELEASE_1 project
$ edit some files
$ cvs commit# This will only affect the RELEASE_1 branch

What I describe above is more or less the same policy that FreeBSD
uses to tag and branch versions.  It's described in the ``FreeBSD
Release Engineering'' article, which you can read at:

http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/releng/

- Giorgos


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message