jeetu mahtani <[EMAIL PROTECTED]> wrote:
> [ ... ]
> Since we may need to do patch releases in the interim I have both of
> them working in their own branches to isolate Main.
The usual approach is to start a support branch at every release
point. Your patch release would be done off the support branch
and (probably) merged to the trunk. Your support branch would
contain zero new features. Features belong to the trunk, in
preparation for later releases.
Doing it that way, both of your enhancements could probably have
been done on the trunk. Doing development on a branch is a bit of
trouble, as you are finding out, so it is normally done only if
the work is speculative and you want to isolate the trunk from it.
> [ ... ]. The first developer with the long term enhancement
> needs to see the enhancement done by the second developer (for some
> reason) so how I bring his branch up to do?
The way I said before: transfer his work to a new branch and kill
the old one.
: (initially on the oldbranch...)
cvs commit : to oldbranch
cvs update -A : return to the trunk
cvs tag newbranch_bp : mark where you are
cvs tag -b newbranch : start a new branch
cvs update -r newbranch : get on newbranch
: bring in the work from the old branch
cvs update -j oldbranch_bp -j oldbranch
: fix conflicts
cvs commit : to newbranch
> I guess by tagging the
> Main at the appropriate point in times, I can update his Branch but it
> just seems such a cumbersome and time consuming process (of
> continuouslly tagging and keeping track of tags).
Updating the branch is not the problem. The problem is when you
try to merge that branch back when the work is finally done.
Unless you planted tags at just the right places and use them
in your merge, you'll get spurious conflicts. It's best to
merge unidirectionally, always from branch to trunk.
--
pa at panix dot com
_______________________________________________
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
