Using the branch, modify, merge paradigm

[Daklu]

At work we are using TFS and follow the branch, modify, merge pattern for code development. This can cause all sorts of problems when code collisions occur in classes or project libraries, such as what might happen when multiple developers change the class .ctl or library VIs are added or removed. What process steps do you go through when resolving conflicts like this to avoid broken projects?

[dannyt]

At work we are using TFS and follow the branch, modify, merge pattern for code development. This can cause all sorts of problems when code collisions occur in classes or project libraries, such as what might happen when multiple developers change the class .ctl or library VIs are added or removed. What process steps do you go through when resolving conflicts like this to avoid broken projects?

Hi we use the same branch - modify - merge pattern, we only have six developers here and the only advice I can give really is communication between the developers.

That said some guide that help us (and only help they do not solve the problem) are :

• we do have a simple web tool so at a button click anybody can see what files other people have out on branches (very useful)
• Plus we try and keep the work / architecture spilt but it never really works.
• merge often / merge often. This is key and also relates to branches on text code. Keep branches as simple as possible and merge as often as possible. I strongly agree with this
• if one of use is doing a change that will result in lots of recompiles we plan that change in with everyone else.

This is the one MAJOR problem I have with LabVIEW and to me it is a major problem. It is bad enought with six developers I cannot even imagine what it would be like with 50 + developers and yet this pattern works fine with 100+ developers with text languages...ah well not point in wishing it will go away.

Dannyt

[Aristos Queue]

When you're working in the same branch as your fellow developers, VIs and .lvclass files should be locked when you check them out. Ideally, you should get a warning when you try to check out a file that says "this file is already checked out. Any changes you make may not be able to check in. Are you sure you want to check the file out?"

When you're working on different branches, I don't have any answers for you other than coordinate with your fellow developers. It's a largely unsolvable problem.

this pattern works fine with 100+ developers with text languages...ah well not point in wishing it will go away.

Multiple branches can quickly break down in pure text languages too. True, changes can *often* be integrated together, but often they can't. LabVIEW has every function as a separate file, which is nice -- its surprisingly rare for multiple developers to need the same function simultaneously.

The private data control of LV classes are a nasty bottleneck. As rare as it is to need to change the same function, two developers needing to add data to a class is more common. I don't really have a solution for this. The closest you can come is to check out the class, add a placeholder typedef and quickly check the class back in. Then in your own code, update the typedef to the data you actually need. This assumes you're not flattening the class to disk and trying to store data of this class type.

[Daklu]

• merge often / merge often. This is key and also relates to branches on text code. Keep branches as simple as possible and merge as often as possible. I strongly agree with this

I agree with 'check in early, check in often,' but merging often (every day or so) kind of defeats the purpose of branching in the first place doesn't it? If you're going to merge every change back into the trunk why not just do the dev work on the trunk?

When you're working on different branches, I don't have any answers for you other than coordinate with your fellow developers. It's a largely unsolvable problem.

The private data control of LV classes are a nasty bottleneck. As rare as it is to need to change the same function, two developers needing to add data to a class is more common. I don't really have a solution for this. The closest you can come is to check out the class, add a placeholder typedef and quickly check the class back in. Then in your own code, update the typedef to the data you actually need. This assumes you're not flattening the class to disk and trying to store data of this class type.

Yikes! I understand why it's unsolvable, but still... yikes! In the case of simply adding or removing VIs from the library it's possible to do a text merge on the .lvclass file, but frankly doing that worries me. I'm never confident that I'm not accidentally breaking something in one of those flattened data fields.

I would hope for the Merge and Compare tools to be expanded to include library files, but sadly that idea wallows at only 9 kudos while the fluffier ideas get all the attention. (I'm not saying that the top ideas aren't useful -- they are -- but they tend to focus on making existing functionality slightly easier to use instead of adding functionality to address difficult problems.)

---------------------------------

We've been following the 'Branch per Component' pattern for our current project, a test sequencer. (Don't ask.) We try to keep the trunk stable and working so our internal customers have a single place they can retrieve the latest working code. Our process for developing a new test case roughly follows these steps. Some of these steps may be unique to TFS; I don't have much experience with other scc systems:

1. Create a branch for the new test case and check the branch in. (This check in is an exact copy of the trunk but having this in the branch makes it easy to find the base version when doing 3-way merges.)
2. Add code for the new test case. When changes are checked into the trunk, forward integrate them into the branch.
3. When the new test case code is complete, do a final forward integration from the trunk to ensure all the latest changes are included.
4. Assuming everything works, reverse integrate the branch into the trunk.

Now, since merging classes 3-ways appears to be unworkable, any time a developer edits a class in a branch, if that class also exists in the trunk he should apply a lock to the class in the trunk preventing other developers from checking it out. Once those edits are done the developer can check the changes into his branch, merge the class back into the trunk, and remove the lock. All the other developers then need to make sure they get the latest version of that class.

This seems like a very error-prone way to handle the inability to do 3-way class merges. Any mistake that allows two developers to make changes to the same source code is going to result in lots of wasted time while one of them to rewrites their code against the other's changes. (Which, coincidentally, is where I find myself right now.) It makes me wonder if the branch-modify-merge pattern is the best one for us to use. Unfortunately the other patterns have issues of their own. I'll have to think on this for a while.

[Aristos Queue]

Unfortunately the other patterns have issues of their own.

I honestly believe there is no good solution. You have to choose the option that is least bad for your particular development team. For me, branches are the worst option, but I can easily understand someone believing single-trunk development being the worst.

Perhaps all software teams should just have an uber secretary who keeps track of everything and let that person tell you what you can develop today.