Tortoise SVN Demo Repository to demonstrate Merge

[SteveE]

While experimenting with Torsoise SVN (V1.9.5) and LabView (2015) I am struggling to get Tortoise to merge. I started with a simple project, a single VI with a few buttons. The project and VI were committed to the trunk, I branched the trunk. I modified the trunk VI and committed. I modified the branch VI and committed. I tried to merge branch back into trunk. Problem is, I always get a conflict.

Is this normal behaviour ?

If I run merge from LV it makes a reasonable attemp and will create a merged file. Tortoise has Merge and Diff setup as per 

https://decibel.ni.com/content/docs/DOC-2936

I post my Repository so that you may try the merge and tell me if it works for you.

Instructions to create the problem:-

From my Demo Repository,

Checkout the trunk to say C:\Test\trunk

Checkout the branch to say C:\Test\branch

From explorer, right click trunk, SVM Merge, Merge a range of revisions, Merge From Demo Repository/branches/Multiply feasability, all revisions,

Test merge. Message says Conflict (maybe) trunk Demo 1.VI

Merge. Message says Conflicted Demo 1.vi, select Resolve all later.

trunk is then marked as conflicted, creates Demo 1.vi.merge-left.r5 and Demo 1.vi.merge-right.r10

From LabView, Tools, Merge, Merge VIs

Base VI = Demo 1.vi.merge-left.r5

Their VI = Demo 1.vi.merge-right.r10

YourVI = Select Demo 1.vi

This makes a reasonable attempt at the merge, needs some tidying up but basically OK

Does anyone have a Demo Repository I could use to demonstrate the merge, and prove if I have a setup issue or not.

[billko]

---

@SteveE wrote:

While experimenting with Torsoise SVN (V1.9.5) and LabView (2015) I am struggling to get Tortoise to merge. I started with a simple project, a single VI with a few buttons. The project and VI were committed to the trunk, I branched the trunk. I modified the trunk VI and committed. I modified the branch VI and committed. I tried to merge branch back into trunk. Problem is, I always get a conflict.

Is this normal behaviour ?

If I run merge from LV it makes a reasonable attemp and will create a merged file. Tortoise has Merge and Diff setup as per 

https://decibel.ni.com/content/docs/DOC-2936

I post my Repository so that you may try the merge and tell me if it works for you.

Instructions to create the problem:-

From my Demo Repository,

Checkout the trunk to say C:\Test\trunk

Checkout the branch to say C:\Test\branch

From explorer, right click trunk, SVM Merge, Merge a range of revisions, Merge From Demo Repository/branches/Multiply feasability, all revisions,

Test merge. Message says Conflict (maybe) trunk Demo 1.VI

Merge. Message says Conflicted Demo 1.vi, select Resolve all later.

trunk is then marked as conflicted, creates Demo 1.vi.merge-left.r5 and Demo 1.vi.merge-right.r10

From LabView, Tools, Merge, Merge VIs

Base VI = Demo 1.vi.merge-left.r5

Their VI = Demo 1.vi.merge-right.r10

YourVI = Select Demo 1.vi

This makes a reasonable attempt at the merge, needs some tidying up but basically OK

Does anyone have a Demo Repository I could use to demonstrate the merge, and prove if I have a setup issue or not.

---

This is expected behavior (and it has nothing to do with LabVIEW).  You have modified the same file in two different places.  That's a conflict.

[Bob_Schor]

I believe this is expected (and designed-in) behavior.

First, note that when you use Subversion with LabVIEW files, SVN can't actually "merge" two VIs of the same name, as they are binary files that Subversion can't "see into" to know how to properly merge them.  [Note that I've not tried to "merge" VIs with LabVIEW's LVCompare -- neither sure it is possible, but certainly I wouldn't want to do it "automatically"!]

So now you have files in the Trunk that have been committed (so the Trunk thinks it has the "starting version" for your current Working Copy), ditto with the Branch.  But when you go to merge the Branch with the Trunk, the "starting version" for the Branch does not match that for the Trunk, so you get a Conflict.

A simpler model is the following:  You CheckOut a Working Copy at work, and CheckOut the same Working Copy at home.  After both Working Copies have been established, you change some VIs at work and Commit your change.  OK, no problems, as the Working Copy says "Everything matches the Head Revision except what I told you has changed".  You go home, do the same thing with other VIs, without updating, and now when you Commit, you get Conflicts because the Head Revision doesn't "match" what your Local Copy says "should be the same as the Head Revision".

Replace Office with "Trunk", and Home with "Branches", and it's the same scenario.

Bob Schor

[tiffyao2048]

Hello Bob,

My team and I use TortoiseSVN 1.9.5 for LabVIEW 2015. Whenever one team member commits their changes to the .lvproj (main project file) to the repository, then the next team member who tries to commit their .lvproj (main project file) experiences conflicts.

Does the scenario you describe apply also to project files and not just VIs? If so, how do team members working on the same project in LabVIEW resolve or prevent these conflicts from happening when using Subversion such as TortoiseSVN?

Many thanks,

Tiffany Y

[Bob_Schor]

I'm a little confused by the idea of "commit changes to the Project (.lvproj) file to the respository".  It sounds like you are doing a "file-at-a-time" commit, as opposed to a "Repository-at-a-time" commit.

Before I say too much more, I should note that I work in a rather small team (typically size 1, occasionally 2-4).  In most cases, I'm dealing with a Repository holding a single LabVIEW Project with 100-1000 files (mostly VIs, TypeDefs, and support files, including Documentation).

I do try to "commit often", at a minimum "at the end of a work period when any changes have been made anywhere in the Project.  I also tend to Commit when I finish a block of code, but before I begin testing (the reason for this is I sometimes make lots of changes during testing, only to revert back to the Last Revision in order to do things "cleanly").

There certainly are times when I forget to Commit (or, conversely, I forget to Update at the beginning of the day, causing problems later ...).  What typically happens in these cases is that I'll get a bunch of Conflicts, but in most cases, the Project File is largely spared.  I think this is because the Project is basically a Text File, and Subversion in many cases can do a reasonable "best guess" of how the old and new Files should be merged.  

In rare cases, however, I've managed to hose the Project file.  In a few cases, I've actually gone in with a fancy Text Editor and tried to do the merge myself, but it is often easier to simply delete the Project File and recreate it by doing an AutoPopulate (this works especially well if you have all of your Project files in a single Directory Tree -- if you pull files from multiple "separated" folders, this will require extra attention).

I've been very happy using Subversion in this manner.  Another VCS that I know some LabVIEW shops with multiple developers have been using is Git, but I have no experience with it.

Bob Schor

[cbutcher]

Like has been described, what you're describing is expected behaviour. Although I use Git, my workflow is much like Bob Schor described above - I try to commit only files that have changed along with a descriptive message of what I changed, but if files are added or removed from the project, the project file will change. You should try to keep the project file changes in the same commit as the new/deleted files, otherwise at least some of your commits won't really be valid states.

Whenever I fail to appropriately commit (or pull) changes from one computer to another, and then discover a conflict, I typically find it easiest to just throw away one copy. I do this by using LVCompare to see the differences (hopefully memorising the smaller set of changes) then keep the larger set, manually adjust the VI to contain both sets of changes (as needed) and then commit that new version.

If you manage to create a conflict with a large number of files, you're more or less hosed. Suck it up and ditch one set then recode - it will probably be faster than trying to merge all of the files individually, especially if any of the changes are complicated.

Although I'm sure you've already seen this, you can minimize the number of files with changes by checking the "Separate compiled code from new project items" box in Project Properties, and marking all existing VIs as separated in the same dialog. This prevents cascading changes causing most of/your entire tree to need to be recommitted when you make some minor change to a typedef or class.

As a side note - I've heard a few people advise setting lvproj files as an excluded type to avoid Git or other SCC tools trying to merge them, since it often ends poorly. I haven't done this myself, but I never try to merge the project file - I always just choose one copy then when I open it I can try readding missing VIs, or re-removing unneeded (and possibly also missing) VIs.

[SteveE]

Tiffany, assuming you have the whole project under SVN, and you are committing the whole project all at the same time. You should not get lvproj conflicts unless the two developers are working in the same section of the lvproj file. When a merge takes place the merge needs to find a few lines either side of the change to correctly identify the place in the file that the change needs to be made.

Example if you commit an empty project and two developers add a single VI and then commit, the VIs will commit as new additions, the lvproj file will be conflicted. This is because SVN sees both commits in the same place in the lvproj file. 

If you apply a little forward planning you can prevent the lvproj conflict

Create an empty project, create two virtual folders, one for developer 1, and one for the other. Commit. Each developer works in their own virtual folder then commits, there will not be a conflict.

In reality you would not have virtual folders for developers, but you would have them for modules in your solution.

Normally as the Project gets more complex conflicts in lvproj are less common as two developers are less likely to be working in the same area.

Regards - Steve

[tiffyao2048]

Thank you Steve. I believe you illustrated our issue very well. Oftentimes, our lvproj file will be conflicted because two developers will each add a new VI or a new library, rearranging some of the VIs in the project. At this point, one developer will commit his changes, and if the other developer updates her working copy before committing her changes, a conflict will arise in the lvproj file. At this point, resolving the conflicts are a bit tricky.

Also, even though both developers are working in different areas of the project, there may be shared libraries, global variables, and shared subVIs used between them. Do you have any suggestions for how to address these issues?

Thanks,

Tiffany Y

[tiffyao2048]

Thanks for the advice, cbutcher. I will try out your suggestions, including checking the "Separate compiled code from new project items" box in Project Properties. I hope this takes care of the issue, and I am glad this discussion gave me more insight into the build and structure of a LabVIEW project.

[billko]

I believe that using autopopulating folders instead of virtual folders makes a lvproj conflict a lot less likely.  I think this is because the lvproj isn't keeping track of where the files are.