GitHub and merge conflict on LVPROJ

[FM82]

Good morning to you all,

I was trying GitHub for source code contro. Playing with commits, pushes and branches wasn't a problem until i simulated two branches, working on the same project, that incorporate two distinct features: Feature_A and Feature_B. In my mind this will simulated two developers collaborating on the same software.

When it was time to merge into the main branch the first merging (Feature_A) goes smooth but when i try to merge the second branch a conflict was generated by GitHub on the LVPROJ file. I undestrand why, both feature's branches modified LVPROJ so Git need to know how to merge this, and I was able to resolve this pretty quicly by manually correct the conflict. But this was a simple test project, with few VIs so the LVPROJ file was simple and straightforward, but what appens when the project grows with classes, actors and virtual folders?

How do you handle this situations?

Many thanks in advance,

Francesco

[rolfk]

Only manually!

This doesn't even work fully automatically for C files, which for the most part can be treated just location based. As soon as you have changes in the same or closely adjacent location in a file, the automatic merge basically has to declare defeat.

The XML structure of the LabVIEW project makes this more complicated as a change in one place can have influence to some part of the file elsewhere that are logically connected and if you have any overlap of the two branches this will almost inevitably lead to corruption of the XML structure. The merge tool would have to learn to fully dissamble the XML structure into its individual objects and then merge them logical syntactically instead of just location based.

There has been some research on such merge tools but nothing that could be considered universally usable. And as you can imagine it is a much more performance hungry operation in comparison to simply comparing a text file text line for text line, and it needs to be done for every format specifically and in the case of XML you also will need to consider XML schema specialities.

[FM82]

Thank you, Rolf.

So, what can we do? Working only one at a time for one project? I fear that manually correct the conflict on the project file will, soon or later, end in corruption of the project itself.

Maybe the only solution is to work independetly for the set of feature that need to be implemented, than use lvlib to share the code and let only one developer to integrate the new feature... 

Francesco

[Yamaeda]

There are some ways to handle this. Me and a coworker used private lvprojs for developing and only had a build-proj in the repository. Another variant is to set lvproj to be handled as binary, then it's be a version conflict and it'll force you to open both and fix it manually. Both are better than getting a bad text merge of the xml. 🙂

[FM82]

I can't understand what you mean by "used private lvprojs for developing and only had a build-proj in the repository". The way of the binary file is the same we use right now but it seems to me to be prone to mistakes.

[Yamaeda]

---

@FM82 wrote:

I can't understand what you mean by "used private lvprojs for developing and only had a build-proj in the repository". The way of the binary file is the same we use right now but it seems to me to be prone to mistakes.

---

We simply used our personal Documents folder for a lvproj that thus wasn't in any repository. 🙂

[JÞB]

Computers and code are great for making the same decisions over and over. human judgments are not very automatable.  You have just proven that intelligence is not obsolete!

Huff on on your knuckles and polish them on your shirt!  I feel pretty good about being smarter than the average byte!

[billko]

---

@Yamaeda wrote:

---

@FM82 wrote:

I can't understand what you mean by "used private lvprojs for developing and only had a build-proj in the repository". The way of the binary file is the same we use right now but it seems to me to be prone to mistakes.

---

We simply used our personal Documents folder for a lvproj that thus wasn't in any repository. 🙂

---

So you each had what amounts to a "temporary" lvproj just so you can organize the library you're working in, and when the time came to merge, you used an entirely new lvproj, had one person add their library and commit, the next person checks it out, adds their library and commits, etc?