Hello Chris,
Thanks for your input. Sorry to bother you, hope
you don't mind. I wanted to make sure I am getting this right because I
am new to SCM and CVS.
Sure
thing! I don't have time for a complete response so all you get is snippets
for right now :)
This
is interesting. So you say you have branches for weekly release that get
merged into the head once changes have gone live. And you have early branches
for larger projects. Any reasoning why this may be the case? Why not develop
on the head and then branch it once the release is live for bug
fixes?
This is for QA. They QA the stuff before it goes out, and
at that time they don't want to see a lot of exciting new development...
just fixes. However developers want to develop. So branching before the
release allows both parties to be productive. So for
weekly releases the branch indicates "ready for QA". For large releases the
branch is a way to isolate long development cycles from the weekly releases.
And you
merge this early branch with the head as well once development is complete or
when project gone live. How does merging work in CVS? Is the branch still
valid? What about bug fixes that would be necessary after a
release? Any problems you
encounter while merging for a web-based environment, I have not tried it here
because I am not sure about the consequences. Also you say that pple do the
changes on the release branch as well as the head even though they don't have
to, how does this affect merging? Does CVS check for the file content before merging?
And what if the developer has put in changes in a different manner for the
same file at the release branch and the head, how does this affect
merging?
Most
of these questions are answered in the CVS FAQs, except for the one about
simultaneous changes to the release branch and mainline. This appears to be
strongly dependant on how they did the change. If they did it by *copying* the
file from one to the other, there's no conflict. If they did it by making the
same change in both places with an editor, then there's a conflict.
Too
many questions :) Any ideas from others appreciated...
Thanks, Brian
We
have a similar environment, number of developers, and web-based
solution.
The process I selected is as follows:
We've been going with a regularly scheduled weekly
release branch for most changes. This gets merged back in after the weekly
release. For larger projects, we've been going with an early branch (say a
month out) which doesn't receive any of the changes for the (say) 4 weekly
releases until the week before it goes out. Then it too gets merged in with
the mainline, and the normal-weekly-branch is made as usual, except that it
contains the month-long changes as well.
So
developers either develop in the mainline (for the next scheduled release),
in the early branch (for the long-term release), or do bugfixes in the
normal-weekly-release branch. No need to make changes in two places at any
time, since the weekly-release branches are the only thing that goes out.
People do it anyway though.
Hello,
Since branching is the most
complicated of the basic source control activities, I have a question
regarding large scale development strategies. What kind of branch
management strategies are more commonly used for Web-based live
environment projects? 1. Task Branches off the trunk or 2. Integration
Branches off the Trunk or a different combination.
Our development effort
includes 20-25 developers, a large CVS repository with multiple projects
and tens of thousands of lines of code. Currently we use simple branching
and work on both the branch, the head and other branches if necessary. The
same code changes go into multiple branches. How do we go about reducing
the development effort and restricting developers to make changes only on
a certain branch? Or do we change our branch management
strategy?
Any input
greatly appreciated, Thanks.
Brian
Sequeira
Build & Configuration
Real Media
580 Virginia Ave - Suite
200
Fort Washington PA 19034
Tel: 215.654.8376 x556
Fax:
215.591.0704
address@hidden
www.realmedia.com
- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- Real Media is a PubliGroupe company - the largest and oldest media
services
- organization in the world. Real Media provides marketing solutions
to the
- digital advertising industry through state of the art technology,
maximizing
- brand value by protecting audience information. Real Media's
customers
- include Bloomberg, Weather.com, New York Times Digital, U.S. News
& World Report,
- GOLFOnline, Investors.com, Forbes, USA Today and mp3.com. For more
- information please visit www.realmedia.com.
- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-