This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Grokking Bitcoin and have Kalle Rosenbaum on-line!
See this thread for details.
Win a copy of Grokking Bitcoin this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

How learn how to resolve merge conflicts with p4Merge ?  RSS feed

 
Greenhorn
Posts: 26
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I wanted to learn how to resolve "challenging" merge conflicts in Java code using p4merge (preferably). I found some beginner level tutorials which only show trivial examples of resolving conflicts with p4merge. I could resolve them without p4merge, by just looking at the conflict markers. I want to learn harder examples and all the features of p4merge used for resolving conflicts. How can I do that ?

BTW, I could not find any on-demand tutorials on Helix's website. I could not find anything on udemy, pluralsight and lynda. I wonder if I should be using another tool (say kdiff3) which might have tutorials with non-trivial examples. Then, after mastering one tool, I could probably teach myself p4merge. Is there any other tool which has better examples ?

Thanks !
 
Ranch Hand
Posts: 522
Chrome Linux VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What's your workflow like, and why is the merge so challenging?  The model I always used when adding a feature or fixing a bug was:

10.  Make a new branch from the trunk
20.  Get my code working on my branch.
30.  Merge the current trunk into my branch, this picks up changes other people have checked in.
40.  Get my code working on my branch.
50.  If I had to change my branch after the merge from 30, then goto 30.
60.  Merge my branch back to the trunk.  
70.  Ensure my stuff still works.

I've only had 1 time where I couldn't do a merge.  I was fixing a bug, while doing so I found/fixed another bug, this cascades until I'd fixed about 10 known bugs and a few that hadn't been detected yet.  When I went to  merge my code I found out another guy had made massive changes to the same code and our changes were incompatible.  After talking to the other guy for a bit we took it to my boss.  He decided to let the other guy deal with it, I got put on a high priority bug that I tracked down to hardware.

I used this model with both Clearcase (good, but expensive, slow, and required kernel changes) and Perforce (love it)
 
Jim Venolia
Ranch Hand
Posts: 522
Chrome Linux VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I should add, the whole point is to not have challenging merges.  As you work on your feature/bugfix, merge the trunk into your branch every day or two so you don't have challenging merges.  In the example I gave above the other guy (wish I could remember his name) checked his changes in about an hour before I tried to check mine in.
 
Saloon Keeper
Posts: 20643
122
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow, someone still uses Perforce? I hadn't heard that name in years!
 
Jim Venolia
Ranch Hand
Posts: 522
Chrome Linux VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What's wrong with Perforce?  It's a great tool for SCM.

Granted, I never learned git. Didn't need to, I've got Perforce.
 
Tom Joe
Greenhorn
Posts: 26
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jim Venolia wrote:What's your workflow like, and why is the merge so challenging?  The model I always used when adding a feature or fixing a bug was:

10.  Make a new branch from the trunk
20.  Get my code working on my branch.
30.  Merge the current trunk into my branch, this picks up changes other people have checked in.
40.  Get my code working on my branch.
50.  If I had to change my branch after the merge from 30, then goto 30.
60.  Merge my branch back to the trunk.  
70.  Ensure my stuff still works.

I've only had 1 time where I couldn't do a merge.  I was fixing a bug, while doing so I found/fixed another bug, this cascades until I'd fixed about 10 known bugs and a few that hadn't been detected yet.  When I went to  merge my code I found out another guy had made massive changes to the same code and our changes were incompatible.  After talking to the other guy for a bit we took it to my boss.  He decided to let the other guy deal with it, I got put on a high priority bug that I tracked down to hardware.

I used this model with both Clearcase (good, but expensive, slow, and required kernel changes) and Perforce (love it)



The problem was that I had branch which was used only by a few people. Some dependencies were changed in the main branch and that caused a lot of code changes which would impact my branch. The problem is that I had not merged main into my branch for a long time - bad). But, that would not matter anyway because the changes for the new dependencies were merged in one big commit. Ex. We have 100's of functions which use a class to make some calls. That class is replaced by another class from the new dependencies. So, 100's of functions are impacted.

Luckily for me, I did most of the code my branch. So, I knew what to do to resolve those merge conflicts. But, it was a pain.
 
Jim Venolia
Ranch Hand
Posts: 522
Chrome Linux VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see a couple issues here.  First, unless you have a team working on a new feature you should not share branches.  Even then I'd argue you make a branch, then your team members make their own branches (twigs?), work on their part, and keep up to date with your feature branch. Someone is in charge of keeping your branch sync'd with the trunk.   In my experience, even when making a new product we each had our own area of responsibility.  After all, if I'm editing foo.java and you're editing foo.java on a daily basis then Here There Be Dragons.

Second, you didn't do the backmerge often, which you acknowledge.

Third, you don't do a change that impacts 100s of functions without a good plan on dealing with it.  Kinda like "um, we're gonna mess y'all up.  You have until friday to merge your stuff back to the trunk, then sit back and drink coffee until further notice".  This puts the responsibility for conflicts where it belongs:  the idiots impacting 100s of functions.


 
Police line, do not cross. Well, this tiny ad can go through:
Create Edit Print & Convert PDF Using Free API with Java
https://coderanch.com/wiki/703735/Create-Convert-PDF-Free-Spire
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!