[p4] Integration messiness

Brad Holt brad.holt at autodesk.com
Mon Sep 11 14:21:49 PDT 2006


This looks like a probably culprit (we're on 2005.1).  One of the
problems that I have seen that I can confirm is to do with a confusing
common ancestor.  There was code that was taken out of the main, that
change made into the child branch so that the code was effectively
removed from all the related branches.  However, when the
grandchild->child->main integrations happened, it reintroduced the code.
Since it was missing in all branches, it looks to me like it was caused
by the common ancestor's inclusion of that old code (basically the
common ancestor went back too far).  It's pretty damned subtle, but it's
done us a bit of damage.  Still don't know if this accounted for most of
the problems or not.

-----Original Message-----
From: Weintraub, David [mailto:david.weintraub at bofasecurities.com] 
Sent: Monday, September 11, 2006 5:54 AM
To: Brad Holt; Perforce Users
Subject: RE: [p4] Integration messiness

P4 versions before the last version (2006.1) used a different merging
algorithm which does not do a very good job when you have two branches
that merge information back and forth between each other. Before this
latest version, Perforce considered all versions on the other branch not
previously integrated. This works fine when you are mainly merging in
one direction, and works for multiple uni-directional merges, but can
cause problems with bidirectional merging.

In the latest release notes, #96464 states that Perforce uses a
"[b]etter base selection using a 'closest ancestor' approach. And that
the previous versions of Perforce "[a]lmost invariably stuck to the
stuck source to the source file when selecting the base. Now any
revision of the source, target, or indirectly related files is a
candidate, with the revision that shares the most changes with both the
target and source being selected".

If you haven't upgraded to 2006.1, you might want to consider upgrading
in order to take advantage of this new merging algorithm (and let us
know how well Perforce has implemented it).

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Brad Holt
Sent: Friday, September 08, 2006 4:52 PM
To: Perforce Users
Subject: [p4] Integration messiness

Hello All,

I've got a team that is running into trouble with integrations from
their branch.  We've been using branches for years, and at any one time,
we may have 20 or 30 branches out in development, so we've gotten pretty
used to them.  It's all gone rather well in most cases.

This particular branch though is having more than its share of merge
problems when coming back to main.  My hunch is that it has to do with
the nature of the integrations in this branch.  Like all other branches,
it regularly gets integrations up from it source branch (main).
However, unlike all our other branches, it also integrates back to main
quite frequently, so there is regular traffic to and from this branch.
I had seen this a while back with another branch where they had similar
problems, and mass integrated both directions frequently.  The problems
are typically things like changes getting lost, deleted portions getting
reintroduced, and things like curly braces getting badly interleaved.
When trying to trace back how this badness may have been caused, it all
gets remarkably complicated and remains so very subtle.  I have found
that I am seeing more "Merge with Edit" resolves than are typical of
most branches.

So I am hoping that one of you may have zeroed in on some more general
typical workflow problems that can cause these.  We're all windows,
p4Win and P4V, with the P4Win users mostly using Araxis for the
diff/merge.

Sorry to be so general.

-brad

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user



More information about the perforce-user mailing list