It's all about the answers!

Ask a question

Merge Process for Parallel Development


Danil Suits (81177) | asked Sep 08 '10, 12:52 p.m.
I'm finding merge to be such a miserable experience that I'm wondering if we're doing it wrong.

We have two streams sharing a single component. Changes only go from Source to Target. We've created a repository workspace specifically for doing the merge - it flows with both streams, but Target is both the default and current stream.

We merge changes from Source to Target once per week. A specific developer has the responsibility to do the merge every week.

In our initial condition, the repository workspace is one week behind Target. So we first accept into that workspace all incoming change sets. This is always trivial. We change the definition to the repository work space to use Source as the current stream. Now we have many incoming change sets, with some potential conflicts.

We accept the incoming changes.

Problem #1: the most common conflict is a content conflict, but I don't think I've ever seen auto-resolve actually work. I've given up on even trying. Does anybody understand the rules for when auto-resolve will actually merge a file?

Problem #2: When we try to resolve the conflict (by preference using Beyond Compare as our external comparison tool), we're offered a two-way comparison. This is pretty miserable, as we now get to guess which changes we need to keep and which to discard. We end up doubling back to diff the changes in the original streams and try to figure out the right choice from there.

So we fight our way through each conflict, resolving it by hand with extra windows open. When we have them all finished, we then change the repository workspace configuration to restore Target as the current stream. New incoming changes are accepted trivially, and then we can deliver the new change sets to Target.


What makes me feel like "we're doing it wrong" is the fact that we aren't getting a three way compare. Is our process broken?

Prior Art:

Resolving Conflicts with Jazz Source Control
Multi-Stream Development
How to do Parallel Streams?

3 answers



permanent link
Anthony Kesterton (7.5k9180136) | answered Sep 08 '10, 6:26 p.m.
JAZZ DEVELOPER

We have two streams sharing a single component. Changes only go from Source to Target. We've created a repository workspace specifically for doing the merge - it flows with both streams, but Target is both the default and current stream.

We merge changes from Source to Target once per week. A specific developer has the responsibility to do the merge every week.


Hi

One thing you have said that caught my eye - having two streams for this purpose. I don't know what you are doing here - but is there need for the second stream. Could a combination of baselines and snapshots (although you only have one component) be used to identify the weekly "marker" in the stream. Aren't all the developers working in their repo workspaces and then delivering to a single stream. If you are able to keep the single stream - then each merge would be resolved when each person delivers, and so the jump from week to week would be broken into smaller steps.

Also - if the target stream is just an updated version of the previous week - why not overwrite the previous week instead of trying to merge.

I suspect I have missed something fundamental in the way you are trying to work...

regards

anthony

permanent link
Geoffrey Clemm (30.1k33035) | answered Sep 08 '10, 8:22 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Your stream setup is fine. I'd try to merge more frequently than once a
week, to avoid more of those conflicts, but you'll still have some merge
conflicts to resolve, and you should be getting a 3-way merge. I
haven't tried the Beyond Compare merge tool, so I don't have direct
experience with it, but I'd suggest the following:

1: Go to the External Compare Tools page in Preferences, and verify that
the 3-way Conflict Compare invocation strings for Beyond Compare are
correct. If they aren't, please file a bug.

2: Invoke the external compare tool, but before closing the compare
tool, use a process explorer to verify that Beyond Compare tool was
being invoked with the correct arguments, as defined in the External
Compare Tools invocation string definition.

Cheers,
Geoff

On 9/8/2010 12:53 PM, Danil wrote:
I'm finding merge to be such a miserable experience that I'm wondering
if we're doing it wrong.

We have two streams sharing a single component. Changes only go from
Source to Target. We've created a repository workspace specifically
for doing the merge - it flows with both streams, but Target is both
the default and current stream.

We merge changes from Source to Target once per week. A specific
developer has the responsibility to do the merge every week.

In our initial condition, the repository workspace is one week behind
Target. So we first accept into that workspace all incoming change
sets. This is always trivial. We change the definition to the
repository work space to use Source as the current stream. Now we
have many incoming change sets, with some potential conflicts.

We accept the incoming changes.

Problem #1: the most common conflict is a content conflict, but I
don't think I've ever seen auto-resolve actually work. I've given up
on even trying. Does anybody understand the rules for when
auto-resolve will actually merge a file?

Problem #2: When we try to resolve the conflict (by preference using
Beyond Compare as our external comparison tool), we're offered a
two-way comparison. This is pretty miserable, as we now get to guess
which changes we need to keep and which to discard. We end up
doubling back to diff the changes in the original streams and try to
figure out the right choice from there.

So we fight our way through each conflict, resolving it by hand with
extra windows open. When we have them all finished, we then change
the repository workspace configuration to restore Target as the
current stream. New incoming changes are accepted trivially, and
then we can deliver the new change sets to Target.


What makes me feel like "we're doing it wrong" is the fact
that we aren't getting a three way compare. Is our process broken?

Prior Art:

Resolving Conflicts with Jazz
Source Control
Multi-Stream
Development
How to do Parallel
Streams?


permanent link
Danil Suits (81177) | answered Sep 20 '10, 4:39 p.m.

What makes me feel like "we're doing it wrong" is the fact that we aren't getting a three way compare. Is our process broken?


Answer - it appears that the process is fine, but our local tool environment was broken.

A pilot error put the wrong version of Beyond Compare onto the developer's box. It seems that 3 way merge is a Professional Edition feature only; upgrading the software and license restored the expected behavior.

* http://www.scootersoftware.com/moreinfo.php?zz=kb_editions

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.