Post by Sean SextonWe have a main branch for our application, and then an additional
secondary branch for each project or bug fix. When a project or bug
fix is slated for release, we merge the changes for that branch into
the main branch.
My question is regarding the "Integrate" functionality on the check-in
screen. I anticipated that PowerDesigner would attempt to identify
the differences between the main branch version at the time the
secondary branch was created and the last version in the secondary
branch, and then apply those changes to the most recent version in the
main branch. What I've experienced is a very manual process where the
user picks and chooses which changes are made in the repository from a
list of differences between the current Main branch and secondary
branch document versions. Is this just "how it works", or have we
blown our configuration or otherwise misunderstood the tool?
I'd appreciate any wisdom you could throw my way. Thanks.
Sean
I haven't messed with integrate yet but I can say that in general the
MO of any merge is manual. (looked up integrate, it's basically update
but across boundaries you normally couldn't update across) But hey,
you can always click ok... if you're willing to trust the tool to pick
the exact right thing to change in the first place, don't bother going
through the list, there are a bunch of changes checked off and ready
to go, just click OK with authority.
The issue is this
CASE 1
Say you have Class A
Then you branch (we'll call that branch ebf)
You change Main::ClassA to ClassA'
You change EBF:ClassA to ClassA''
Based on your rules you'd blow away Main::ClassA' and replace it with
EBF::ClassA''.
Maybe you that's ok, maybe you've been making any change to your EBF
branch that you've made to Main so A'' has all of A' in it.
PD is unwilling to assume that for you.
That's the hard case.
There are two other simpler cases.
CASE 2:
You add a new class to bugfix, it doesn't exist in Main.
Main::<null>
EBF::ClassB
By default PD will Add that class to Main when you merge the two.
Piece of cake. Don't need to do anything. The check box for that
change will be checked.
CASE 3:
You add a new class to main after you split off bugfix
Main::ClassC
EBF::<null>
Technically in a merge PD will try to make Main look exactly like EBF.
In this case it would have to delete ClassC to accomplish that. By
default PD will not delete that class in Main when you merge the two.
Piece of cake. Don't need to do anything. The check box for that
change will NOT be checked.
CASE 3a:
ClassD existed in Main before you split off bugfix but you've deleted
it in bugfix and you want it deleted in Main.
Main::ClassD
EBF::<null>
Similar to CASE 3. But in this case we want ClassD to be deleted from
the Main branch. Because the more harmful choice (if wrong) is
deleting that Class PD leave the delete change checkbox, unchecked.
You'll have to manually check that box.
Ok, in this case, your method would have checked that off. Comparing
Bugfix to Main at the time of the split would show that ClassD was
there in Main and it's not there now in BugFix so clearly you've
deleted it. You could safely check off that delete. But this isn't so
hard. You can filter the merge screen by change type, you can tell it
to show only drops you can go through them and decide which are new or
which are deletes. If it's a large team and you don't know all the
changes, you could run a compare between the current main and the main
at split time to get a list of classes added or not.
I'm not 100% certain of my descriptions. Feel free to correct or
question. But I believe this is close. I reiterate my earlier
statement. If you were willing to let a tool choose which changes to
migrate, you're fine, just click ok.
In your original post you said you "anticipated". I think the better
word is you "assumed". Why? Why assume? The tool has some great
documentation but, I know, real programmers don't read docs. But how
hard is it to build a little scenario. Make a model with a couple of
classes. Check it in, Branch it, make specific changes to the root
(change one, add one, delete one), make specific changes to the branch
(change one, add one, delete one). Perform an integrate and just click
ok, don't go through the merge window.
Examine the final model.
What changes did you assume would be made that weren't? Is the deleted
class not deleted, or the changed class not changed properly?
Now you have a subset of items to manage manually in the merge
screen. OR... you could always write a little vbscript to handle
those few cases in advance of the merge.