Programmatic LV project conflict resolution

[tobias_l]

Hi Casey,

The user.lib code gets updated quite often from revision control when features are added, bugs fixed, etc.  Each time the library code gets updated, the links must be updated because the links in the revision controlled source are not the same as on the target.  It's not a question of cross-linking, because the destinations in the source files don't exist on the target.  The source files just need to be updated to point to the current project loading on the target.

The project itself doesn't change frequently in terms of the dependencies with user.lib.  Once linked, the same project loads fine the next time.  Having these dependencies means only one project can run at a time which is fine.  Only when I want another project to run would I need to update the common links again.

I know its the classic "links need updating" scenario, and I'm not asking why it happens because I know why.  I'm asking about a programmatic method of accessing the "Resolve Conflicts" dialog functionality.

Toby

[Hooovahh]

Yup totally understand and the way I've been doing reuse means no linking to the actual source.  Only link to the code in the user.lib which has the prefix/suffix added which VIPM does for you automatically.

This is a very common way of doing this which OpenG, and many tools network packages do it.

For this to work you don't checkout SCC to user.lib and only distribute it through a repository management of packages which handles all things like package dependency and configuration management.  Then you aren't left with one monolithic reuse library but have the option to only include packages that are actually used in your source.  This again only works if your package source only links to the installed package in user.lib, and not linking to the source of a different package.  This means package dependency between packages is automatic as well.  I'm a big fan of reuse done well in LabVIEW and even wrote my college thesis on it.