ni.com checkout is currently experiencing issues.

Support teams are actively working on the resolution.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Merging labview project files (lvproj)

Hi,

 

three of us use GIT to develop the same labview project. We try separating the sections we work on, so in most of the cases we dont have a merge conflict on the VI level but because the lvproj file changes pretty much by each change we make, we have an issue merging our work seamlessly. Is there a straightforward way to merge project files?

 

The same question asked here >>>HERE<<<8 years ago.

 

Pls note: this is about merging lvproj files only, not about how to merge VIs

 

Thanks!

0 Kudos
Message 1 of 8
(1,484 Views)

Short answer: Don't.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 2 of 8
(1,458 Views)

@1984 wrote:

Hi,

 

three of us use GIT to develop the same labview project. We try separating the sections we work on, so in most of the cases we dont have a merge conflict on the VI level but because the lvproj file changes pretty much by each change we make, we have an issue merging our work seamlessly. Is there a straightforward way to merge project files?

 

The same question asked here >>>HERE<<<8 years ago.

 

Pls note: this is about merging lvproj files only, not about how to merge VIs

 

Thanks!


I've noticed that if you keep to your respective libraries, even if the project file wants to be saved, it doesn't actually change in content.  Not sure why it even wants to save, but it does.  GIT never considers these saves to be changes.  This is as designed; all the changes to the library are recorded in the lvlib file.

 

The problem is when you actually add something to the project, like a new library or dependency, or a build's property changed somehow.  You should tell GIT to treat lvproj and lvlib files as binary so it doesn't try to be smart and try to merge them for you.  You will then end up with a conflict instead.  Usually you can look at the contents of the files to see which one represents the best choice.  Sometimes you can even merge them by hand.  I've done this before.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 3 of 8
(1,449 Views)

@billko wrote:

@1984 wrote:

Hi,

 

three of us use GIT to develop the same labview project. We try separating the sections we work on, so in most of the cases we dont have a merge conflict on the VI level but because the lvproj file changes pretty much by each change we make, we have an issue merging our work seamlessly. Is there a straightforward way to merge project files?

 

The same question asked here >>>HERE<<<8 years ago.

 

Pls note: this is about merging lvproj files only, not about how to merge VIs

 

Thanks!


I've noticed that if you keep to your respective libraries, even if the project file wants to be saved, it doesn't actually change in content.  Not sure why it even wants to save, but it does.  GIT never considers these saves to be changes.  This is as designed; all the changes to the library are recorded in the lvlib file.

 

The problem is when you actually add something to the project, like a new library or dependency, or a build's property changed somehow.  You should tell GIT to treat lvproj and lvlib files as binary so it doesn't try to be smart and try to merge them for you.  You will then end up with a conflict instead.  Usually you can look at the contents of the files to see which one represents the best choice.  Sometimes you can even merge them by hand.  I've done this before.


I agree. Use libraries and/or classes to separate things and the top level project will not need to be changed often. Each developer would work within a library and therefore their work is self contained and will not conflict with the other developers. I've been doing this for years now and we have very little conflicts within a team of several developers.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 4 of 8
(1,412 Views)

Try this.

"If you weren't supposed to push it, it wouldn't be a button."
Download All
Message 5 of 8
(1,360 Views)

Usually it's the .Alias file.  MyComputer is not the OtherDevolpers computer.  Just excluding *.Alias from SCC repository fixes that.


"Should be" isn't "Is" -Jay
Message 6 of 8
(1,343 Views)

because the lvproj file changes pretty much by each change we make, we have an issue merging our work seamlessly.

As mentioned above, the use of libraries helps to reduce the number of modifications into the LabVIEW project file, but it's not always enough. Some changes may have to be done in the project file (eg: build specification change) and versioned in the source code control system.

 


Is there a straightforward way to merge project files?


I wouldn't say "straightforward", committing the entire project file is the best way to get conflicts and corrupted LabVIEW project files.

 

For me the best way is to cleanup the content of the LabVIEW project file to remove all information generated by LabVIEW (ex: dependencies) and only retain the interesting content for you (eg: statically linked VI, symbols, build specifications...). The LabVIEW project file is an XML text file. If you only keep strict necessary information inside, version management tools like SVN or GIT then do a very well job to merge changes inside the project file.


This cleaning task can be done manually but it is very laborious and repetitive, it can also be scripted. If you are interested in more information I have made a presentation about this subject recently during a LabVIEW User Group meeting (https://www.youtube.com/watch?v=IKeNXx2Tqag&t=34s). The presentation is in French but slides and screenshots are in English.

 

Disclaimer: Warning this is not an official solution, it's just a workaround that I use.

Arcale - CLA, CLED, CTD - LabVIEW 2b || !2b
0 Kudos
Message 7 of 8
(1,202 Views)

@Nicolas_Bats wrote:

because the lvproj file changes pretty much by each change we make, we have an issue merging our work seamlessly.

As mentioned above, the use of libraries helps to reduce the number of modifications into the LabVIEW project file, but it's not always enough. Some changes may have to be done in the project file (eg: build specification change) and versioned in the source code control system.

 


Is there a straightforward way to merge project files?


I wouldn't say "straightforward", committing the entire project file is the best way to get conflicts and corrupted LabVIEW project files.

 

For me the best way is to cleanup the content of the LabVIEW project file to remove all information generated by LabVIEW (ex: dependencies) and only retain the interesting content for you (eg: statically linked VI, symbols, build specifications...). The LabVIEW project file is an XML text file. If you only keep strict necessary information inside, version management tools like SVN or GIT then do a very well job to merge changes inside the project file.


This cleaning task can be done manually but it is very laborious and repetitive, it can also be scripted. If you are interested in more information I have made a presentation about this subject recently during a LabVIEW User Group meeting (https://www.youtube.com/watch?v=IKeNXx2Tqag&t=34s). The presentation is in French but slides and screenshots are in English.

 

Disclaimer: Warning this is not an official solution, it's just a workaround that I use.


Oh, here's my answer to my question in the topic you made.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 8
(1,190 Views)