What is the best way to checkout by tag

Discussion:

Ziggy

2009-11-21 16:49:38 UTC

Here is an example. Lets say the last release was LIVE-REL-2-3
All the necessary modules that make up LIVE-REL-2-3 have been tagged with
the LIVE-REL-2-3

Now i am working on LIVE-REL-2-4 and make changes to 3 files. I check in
these 3 files and tag them with the label "BUG23"

There might be developers who have checked in source files and tagged them
with "BUG22", "BUG44" etc which i do not want to include into LIVE-REL-2-4.

LIVE-REL-2-4 should only include "BUG23" which i have just checked in. To
achieve this, i checkout LIVE-REL-2-3 and any files with the "BUG23" label
and build my application.

This checks out the LIVE-REL-2-3 release
cvs co -r LIVE-REL-2-3 mymodule

This checks out the files that had the "BUG23" label.
cvs co -r "BUG23" mymodule

The above works fine but the problem is i have to run the commands in
separate directories. if i run them in the same directory cvs removes files
in the current working directory. For example

- cd into root folder of working directory
- cvs co -r LIVE-REL-2-3 mymodule
This checks out all files that make up LIVE-REL-2-3)
- cvs co -r "BUG23" mymodule
This removes everything in the current working folder
including the files i checked out on the previous command and only includes
the BUG23 files.

The only way i can fix this is to do the checkout in separate folders and
then put them back into one folder. This is annoying when i am working on
several bugs. isnt there a way to check out using multiple tags?

Thnks

Ziggy

2009-11-21 16:52:21 UTC

Permalink

Oh and i forgot to mention that when i ran the second command, i get the
following msg/warning for everyfile that was not checked out (i.e. removed
from the current folder)

cvs checkout: `/u/myapp/sql/submitPage.sql' is no longer in the repository

Thanks

Post by Ziggy
Here is an example. Lets say the last release was LIVE-REL-2-3
All the necessary modules that make up LIVE-REL-2-3 have been tagged with
the LIVE-REL-2-3
Now i am working on LIVE-REL-2-4 and make changes to 3 files. I check in
these 3 files and tag them with the label "BUG23"
There might be developers who have checked in source files and tagged them
with "BUG22", "BUG44" etc which i do not want to include into LIVE-REL-2-4.
LIVE-REL-2-4 should only include "BUG23" which i have just checked in. To
achieve this, i checkout LIVE-REL-2-3 and any files with the "BUG23" label
and build my application.
This checks out the LIVE-REL-2-3 release
cvs co -r LIVE-REL-2-3 mymodule
This checks out the files that had the "BUG23" label.
cvs co -r "BUG23" mymodule
The above works fine but the problem is i have to run the commands in
separate directories. if i run them in the same directory cvs removes files
in the current working directory. For example
- cd into root folder of working directory
- cvs co -r LIVE-REL-2-3 mymodule
This checks out all files that make up LIVE-REL-2-3)
- cvs co -r "BUG23" mymodule
This removes everything in the current working folder
including the files i checked out on the previous command and only includes
the BUG23 files.
The only way i can fix this is to do the checkout in separate folders and
then put them back into one folder. This is annoying when i am working on
several bugs. isnt there a way to check out using multiple tags?
Thnks

Jim Hyslop

2009-11-21 17:34:36 UTC

Permalink

It sounds like you need a better handle on your release management
strategy, and how CVS will fit into that. Remember that CVS is NOT a
configuration management system, nor even a release management system.
It is a version management tool, which fits into the overall release and
configuration management strategy that you must devise.

Basically, if you have two or more deliverables, which are going into
two or more different releases, you MUST use branches. As you've
discovered, not using a branch is complicating your life horrendously,
and will likely bite you in the rear end when you least expect it.

There are two common approaches you can take.

The first approach, and probably by far the most common, is to use the
mainline for all release development, and create branches for bug fixes.
Generally, use this when your development time tends to be smaller than
the release time, or releases are ad-hoc (e.g. we'll release this when
the features are done). When you create a release, you create a branch
then and there. Any bug fixes are put on the branch, then merged into
the trunk when complete.

The second approach is to create a branch for each release. No
development is ever done on the trunk. This approach is useful when you
have frequent releases (monthly or even more frequently) and you have
some items in development which will take longer than one release cycle
to implement. For example, I'm currently on contract to an organization
that has monthly releases, and we have items scheduled to be delivered
November, December, March and June, so we currently have four active
development branches. When it's time to start working on a release, you
merge a chosen branch (usually the most recent branch for the most
recent release, but it doesn't have to be) to the trunk, then create a
new branch for the release. As each release is released, you merge the
code from that release's branch to the trunk, and to any subsequent
branches (going back to my previous example, we'll have to merge
November's changes into the trunk, and each of the branches for
December, March and June).

Each approach, of course, has its own advantages and limitations.

I have omitted quite a few details here, to keep this email to a
reasonable size :-)

Your best bet would be to create a branch from LIVE-REL-2-3, then
replicate your bug fix on that branch. Release 2.4 will be created from
the branch. If your fixes for BUG23 should be included in 2.5 then
you're done, otherwise you'll have to back out your changes from the trunk.

- --
Jim Hyslop
Dreampossible: Better software. Simply. http://www.dreampossible.ca
Consulting * Mentoring * Training in
C/C++ * OOD * SW Development & Practices * Version Management

Ziggy

2010-07-22 16:29:17 UTC

Permalink

Thanks Jim for the information.

The problem i have is i cant support branching. I would like to but i am
struggling to convince my boss to authorise as he believes it will
complicate things.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

them

Post by Ziggy
with "BUG22", "BUG44" etc which i do not want to include into

LIVE-REL-2-4.

Post by Ziggy
LIVE-REL-2-4 should only include "BUG23" which i have just checked in. To
achieve this, i checkout LIVE-REL-2-3 and any files with the "BUG23"

label

Post by Ziggy
and build my application.

It sounds like you need a better handle on your release management
strategy, and how CVS will fit into that. Remember that CVS is NOT a
configuration management system, nor even a release management system.
It is a version management tool, which fits into the overall release and
configuration management strategy that you must devise.
Basically, if you have two or more deliverables, which are going into
two or more different releases, you MUST use branches. As you've
discovered, not using a branch is complicating your life horrendously,
and will likely bite you in the rear end when you least expect it.
There are two common approaches you can take.
The first approach, and probably by far the most common, is to use the
mainline for all release development, and create branches for bug fixes.
Generally, use this when your development time tends to be smaller than
the release time, or releases are ad-hoc (e.g. we'll release this when
the features are done). When you create a release, you create a branch
then and there. Any bug fixes are put on the branch, then merged into
the trunk when complete.
The second approach is to create a branch for each release. No
development is ever done on the trunk. This approach is useful when you
have frequent releases (monthly or even more frequently) and you have
some items in development which will take longer than one release cycle
to implement. For example, I'm currently on contract to an organization
that has monthly releases, and we have items scheduled to be delivered
November, December, March and June, so we currently have four active
development branches. When it's time to start working on a release, you
merge a chosen branch (usually the most recent branch for the most
recent release, but it doesn't have to be) to the trunk, then create a
new branch for the release. As each release is released, you merge the
code from that release's branch to the trunk, and to any subsequent
branches (going back to my previous example, we'll have to merge
November's changes into the trunk, and each of the branches for
December, March and June).
Each approach, of course, has its own advantages and limitations.
I have omitted quite a few details here, to keep this email to a
reasonable size :-)
Your best bet would be to create a branch from LIVE-REL-2-3, then
replicate your bug fix on that branch. Release 2.4 will be created from
the branch. If your fixes for BUG23 should be included in 2.5 then
you're done, otherwise you'll have to back out your changes from the trunk.
- --
Jim Hyslop
Dreampossible: Better software. Simply. http://www.dreampossible.ca
Consulting * Mentoring * Training in
C/C++ * OOD * SW Development & Practices * Version Management
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksIJKwACgkQLdDyDwyJw+O6yQCdHv2Si5YqyUmkWNdIVz5IWU3e
YMUAnRWClIo8qcW/CVVE6Z8LOgiruC39
=MdPp
-----END PGP SIGNATURE-----

Jim Hyslop

2010-07-24 12:42:12 UTC

Permalink

Post by Ziggy
Thanks Jim for the information.
The problem i have is i cant support branching. I would like to but i am
struggling to convince my boss to authorise as he believes it will
complicate things.

What you need to accomplish is pretty much impossible without using
branches.

Branches do introduce more complexity, but that complexity can be easily
managed as long as you plan ahead.

- --
Jim Hyslop
Dreampossible: Better software. Simply. http://www.dreampossible.ca
Consulting * Mentoring * Training in
C/C++ * OOD * SW Development & Practices * Version Management

grant.schoep

2009-11-26 19:28:36 UTC

Permalink

Ok, see my other reply about what is happening about doing two
checkouts on top of each other. I just wouldn't do it. I need to do
this often enough, I never touch branching. My projects are all
rather smaller, developer wise that is. Its generally me, with one or
two others. The code bases are medium sized, maybe 200-1000 some
files total for each project. But since I am the main developer, and
CM for this stuff, it makes it a LOT easier to do without branching.
And everyone sort of works in their own area.

Anyways. Try something like this

#check out your "initial baseline" build, which was called LIVE-REL-2-3
cvs co -r LIVE-REL-2-3 mymodule

#Now update what you just checked out with the files checked in with
the tag BUG23
cd mymodule #the package you just checked'out
cvs update -dBUG23

That should all there is to do. Hope this works. I may be missing
something, different projects can vary so much, there may be a slight
twist to it that will make it work better/worse for you.