--- Chuck Karish <chuck.karish@xxxxxxxxx> wrote:
> Branch from main at a point where you're sure that
> you'll take
> everything. Integrate features from main to your
> new release branch
> as they're finished.
That won't work in this case, unfortunately. The
4.1.0 code was integrated into main _after_ some
changes were already added to main. That means I
can't get all the 4.1.0 code integrated into my new
branch unless:
1. I also integrate some of the new "main" stuff
(which I don't want).
2. Or I branch from 4.1.0 .
However if I branch from 4.1.0, that'll make it hard
for me to integrate to/from main later. I can get it
to work with some baseless merges (-i or -I), but
there seems to be a lot of repetitive and hard
to manage conflict resolutions once I go down that
road.
> A more radical approach: Make a permanent
> forward-development branch,
> and integrate features from //depot/dev only when
> theu're ready to be
> released. The main line stays clean, the developers
> grumble about
> doing one more integration, the project managers
> love that release
> readiness is predictable and that they control
> release contents.
I'll likely utilize this approach at a latter
date, but I still fear issues like this:
main
|
+-- dev1
|
|
+-- dev2
Both dev1 and dev2 are branched from main. What do
I do if the dev1 folks want some of the dev2 code?
I can integrate dev2 to main, and then main
to dev1, but then my main codeline will have
some stuff that may or may not ever go to
production. Alternatively, I can baseless
merge dev2 to dev1, but that will reintroduce
the long-term problems of baseless merging.
Dave
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
_______________________________________________
perforce-user mailing list - perforce-user@xxxxxxxxxxxx
http://maillist.perforce.com/mailman/listinfo/perforce-user
|
