Programmatic LV project conflict resolution

[tobias_l]

Is it possible to programmatically perform the "Resolve Conflicts" operations when a project contains conflicts?  I can get a list of references that are in conflict from the project properties node, but haven't found any way to tell the project which reference is the one I want to use, namely the "Use Selected Item" function from the "Resolve Project Conflicts" dialog box.

In my system I have a set of common libraries in user.lib that have links to the active project instance elsewhere on disk (yes I know, I am working on eliminating them).  When a user switches projects those links need to be updated and since I know the active project I feel it should be possible to safely re-link to the project path automatically.  Am I missing something?

Thanks,

Toby  

[CaseyGj]

I am not immediately aware of a way to bypass the Resolve Conflicts dialog without manually stepping through it. 

Could you describe your issues and application in a bit more detail so we could try to find a way around having to resolve conflicts every time?

[tobias_l]

Hi Casey,

The conflict situation arises from having common library functions in user.lib that reference typedefs/VIs defined in a project folder elsewhere on disk.  The project folder is a common framework that contains typedef/VI customizations required for that project, but still leverage the common libraries rather than make copies of the common functions and store them with the project.  This is to facilitate updates to common functions - only need to update one location. 

When Project A loads, the common functions look for their typedefs, which are found in Project A folder and once re-linked, everything is well.  When Project B is loaded, the common function links to Project A need to be re-linked to Project B via Resolve Conflicts.  Conflicts are always resolved simply by selecting the path to the current project - I just want to make a small utility to do this programmatically. The Project property node gives a list of conflicting paths (Project A), but I haven't found a way to programmatically "Use Project B" i.e. automate the Resolve Conflicts Dialog.

I've tried other things as well like mass compile, putting the project in the VI search path, adding/removing/replacing common functions from the project, etc.. but I always have to re-link manually when I switch projects.

Any suggestions would be appreciated!

Toby

[CaseyGj]

How often are you making updates to the code for these projects?

Is it a situation with frequent development, or are you just opening these projects to run the programs?

[JÞB]

---

@tobias_l wrote:

Is it possible to programmatically perform the "Resolve Conflicts" operations when a project contains conflicts? 

---

I want to say "Not just NO but, <self censored expletive>  NO!"

Here is my reasoning,  I said some component of the project I wish too deploy should be like so and contain such and stuff,  Then the component of my project went wonky.  (Changed location, got updated, changed connector panes, just stopped working, WHATEVER!)  Tab + <Enter the Dragon!>  

Grasshopper, you should observe and overcome the conflicts presented by your fellows.

[Hooovahh]

The way I avoid this is by using VIPM for creating and installing the reuse library functions which go into user.lib.  When the package is build there is a setting to append a prefix or a suffix to all the files in the package.  Now when I have my source I'll have a VI like "Do awesome work.vi" but once the package is installed in my user.lib I will have "Do awesome work_hooovahh.vi" and that prevents code from linking to the wrong files.

[Gregory]

---

@Hooovahh wrote:

 Now when I have my source I'll have a VI like "Do awesome work.vi" 

---

Hi Hooovahh, is there any chance you could share that VI or is it your company's property? 🙂

[Hooovahh]

---

@Gregory wrote:

---

@Hooovahh wrote:

 Now when I have my source I'll have a VI like "Do awesome work.vi" 

---

Hi Hooovahh, is there any chance you could share that VI or is it your company's property? 🙂

---

Actually I just have a library called "Do awesome work", and then put all VIs I write into it, because every VI I write does awesome work.

[tobias_l]

I really don't think renaming common library files to avoid conflicts is the right approach to maintaining a revision controlled common library 😉

[tobias_l]

Wow Jeff what's your real opinion 😉

So to paraphrase, your suggestion is to use a different architecture.

You say it would be bad to allow programmatic selection of the links I want the project to use when there's a conflict.  I'm not asking for the project to magically select a resolution itself, I just want to do the selection without having to click dialogs for "Select Path", "Use this File", and "Yes" to save affected files.  Doing this via project properties/methods would be the exact same thing that is happening with manual selection, so what is soooo bad to warrant expletives?  The project already gives a list of conflicting paths via properties, I just want to programmatically delete the invalid ones.

Toby