In TFS specifically, cherry picking where namespace changes are involved is just asking to get burned.But these guesses are in no way known to or validated by your SCM tool chain. "I'm merging all the changes affecting Module Foo, and I tested the new version of Foo in Dev, so that's how Foo will behave in Integration, right?" you can track every dependency in your head (including everything that may have changed in Integration while you were testing Dev). You can make a decent guess about the final state of the target branch. The set of changes you're promoting into the supposedly more stable branch represents a configuration that has never been built or tested before.No diff tool is perfect you're adding a nonzero risk of bringing over more code than intended, accidentally overwriting changes made in the target, introducing logic bugs where the two branches diverge, etc. If any of the files touched in your range were also touched previously, you'll have to do a 3-way content merge so that only the cherry-picked diffs are propagated.For that alone, Laura Wingerd would say you're jumping over a curb. You can't use the merge down, copy up model described above.Any changeset range that skips #10 is known as a "cherry pick." Once you start cherry picking you run into a few hazards: If changesets 10, 20, and 30 are candidates to merge from A -> B, then any of these merge ranges is a "catch up:" 10~10, 10~20, 10~30. That is, merge things in the same order they were checked in. Do "catch up" merges whenever possible.If you anticipate a "big bang" merge of death for whatever reason, there's a decent chance locking will block other teams from doing the same thing in parallel, so you may have to iterate thru steps #1-4 repeatedly until you're ready. If the Dev branch is accepting merges early & often, like it should be, then it shouldn't be burdensome to lock the target branch during this hopefully-short process. Ensure there are no changes in the target branch between step #1-4.Use the source branch (Dev #2 in our case) to fully incorporate, react to, and stabilize these changes.AcceptMerge (either auto or manual) is usually the desired result but sometimes you'll want to take one or the other branch's copy unchanged. ![]() If there are conflicts, handle the diffs on a case by case basis.Integration -> Dev2) to pick up the latest changes from the target branch. First merge in the other direction (e.g.This is the safest way to preserve the stability of your downstream branches. Merges from Dev* -> Integration and Integration -> Production should always be "copy" merges.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |