LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can Project Files (.lvproj) and Project Libraries (.lvlib) be merged by Subversion?

I've been using Tortoise SVN with LabVIEW for a long time (at least 5 years).  Most of the time, I'm a "sole developer", and try to remember to "update first, work on code, then commit", but sometimes I forget, and get conflicts.  No big deal, figure out which of the three versions "My Code.vi, My Code.vi.2314, My Code.vi.2325" is the right one, and delete/rename as necessary.

 

Side note -- if I want to use the LabVIEW Compare tool, I rename the two "revision" files by adding .vi to the name.  Now they are legitimate VIs, and have unique names so LabVIEW can safely open all three.  Once I decide which I need to keep (say it is My Code.vi.2325.vi), I just delete the unnecessary extension.  In my case, Windows is set to not show extensions that it "knows", so what I delete is the ".vi.2325", and the not-shown ".vi" is still present.

 

However, sometimes (like today) there is are differences in the Library or Project files.  Subversion seems to treat them as text-like files, as it merges them.  Is this safe?  I was thinking of modifying the SVN Configuration file to make these file types "binary", so that a "conflict" in, say, the Project would trigger a Conflict Error.

 

I'm interested in opinions/experiences/warnings before making a firm decision.  It would seem to me (naively) that a "conflicted Project File", meaning one that is consistent with a particular Repository revision, but might not be 100% consistent with the current Working Copy, is "safer" and potentially easier to patch than a file that Subversion has "cobbled together" from two differing Project Files, as it has no a priori knowledge of how LabVIEW constructs these files.

 

Bob Schor

0 Kudos
Message 1 of 7
(3,653 Views)

Every time I see SVN merge my project file, I am watching for it to be corrupt.  More often than not, it is.  So if you can get SVN to treat it as a binary, I would highly suggest that you do so.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 7
(3,617 Views)

That's easy to do.  I've done it on one of my PCs (today), and posted here in case anyone has already tried this and found some adverse effects.  If I'm the first to do this, I'll report back in a week or so on my findings.

 

BS

0 Kudos
Message 3 of 7
(3,607 Views)

I also use Subversion with the TortoiseSVN client, but I've always simply had it consider all of my LabVIEW files (VI's, .lvlib, .lvproj, .lvclass, etc.) as binaries.

 

However, aren't .lvproj and .lvlib simply XML files?  That should mean that they are plaintext and that TortoiseSVN would at least be able to see inside of them.  If this is the case, then I wouldn't expect the default plaintext diff/merge tools to cause problems and corrupt them; perhaps there is a set of diff/merge tools that are somehow more XML-aware so that it could diff/merge these properly?



0 Kudos
Message 4 of 7
(3,586 Views)

While the files are XML, I'm not sure they are fully standard XML. Even if they are, they have all kinds of data in them which requires special knowledge. For instance, libraries have icons (which are binary) and versions. Classes have a wire and control. Projects have arrays of elements which are encoded in a certain way, etc. In short, don't merge them. Also, note that current versions of TSVN auto-merge conflicts by default when you update and you need to jump through some hoops to disable that.

 


@Bob_Schor wrote:

Side note -- if I want to use the LabVIEW Compare tool, I rename the two "revision" files by adding .vi to the name.  Now they are legitimate VIs, and have unique names so LabVIEW can safely open all three.  Once I decide which I need to keep (say it is My Code.vi.2325.vi), I just delete the unnecessary extension.  In my case, Windows is set to not show extensions that it "knows", so what I delete is the ".vi.2325", and the not-shown ".vi" is still present.

You should be able to configure TSVN to call the LVMerge program on LV files, which should allow you to simply click the original VI and select the conflict editing option in TSVN. No need to do this manually.


___________________
Try to take over the world!
0 Kudos
Message 5 of 7
(3,570 Views)

Thanks, tst, for the comments.  I realize that the title of my Post is wrong -- I agree that letting SubVersion merge .lvproj and .lvlib files is problematic.  I've turned it off on one PC, but want to know if there are disadvantages to preventing Subversion from merging these files.

 

My plan is to experiment with merging turned off, and see if any "gotchas" pop up.  I plan to post my experiences here ...

 

Bob Schor

0 Kudos
Message 6 of 7
(3,547 Views)

@tst wrote:

While the files are XML, I'm not sure they are fully standard XML. Even if they are, they have all kinds of data in them which requires special knowledge. For instance, libraries have icons (which are binary) and versions. Classes have a wire and control...


FYI, I've had a chance to take a look at a couple project, library, and class files, and it looks like they are standard XML with some properties - including those that you mentioned - using the "Bin" property type.



0 Kudos
Message 7 of 7
(3,544 Views)