How do you organize your code reuse repository

[doradorachan]

Hello.

It's my first time posting on LAVA.

 

I recently posted the same topic on the NI forums, but I wanted more feedback so I am posting it here as well.

 

So my question is how do you guys organize the code reuse repository at your workplace?

Is it on an individual basis or is there a systematic way?

 

Any idea is appreciated, thanks!

[hooovahh]

I kudo'd the second post talking about how the reuse mindset is more important then the actual code.

 

In addition I deal heavily with VIPM, as I hope all reuse libraries do.  Making a package is easy and can install things to the palette, change LabVIEW.INI keys, add tools items, add quick drop functions, add templates, add quick drop shortcuts, add glyphs for the icon edtor, and do all kinds of things.  

 

I work at Magna where we have many packages.  One issue that comes up is if you have a package, that has a dependency of another package, and the second package has a dependency of the first package, then strange things can happen and it is generally a bad thing.  Because of this I have made a handy reuse dependency map.

 

 

I wish this could be done automatically but it probably wouldn't look nice.  Basically this shows each package in our package configuration file, and what internal packages have dependencies on what other internal packages. When making creating new packages, or updating old ones this helps me understand what links already exist, and helps avoid the situation I mentioned earlier.

[Jordan Kuehn]

What did you use to make this? I assume yED can produce something similar, but I like your chart.

[hooovahh]

What did you use to make this? I assume yED can produce something similar, but I like your chart.

I knew I saw something like this.  Thank you I will look into automating it in the future.

[Jordan Kuehn]

I'm not sure if that will help you with automating the process, but maybe.

 

Edit// Please don't derail this topic.  I'm quite interested in the various approaches people use.

[PaulL]

A related thread: http://lavag.org/topic/16235-organizing-your-projects-on-disk/

[doradorachan]

Wow I didnt realize the default setting for notification was off until now.

 

In addition I deal heavily with VIPM, as I hope all reuse libraries do.  Making a package is easy and can install things to the palette, change LabVIEW.INI keys, add tools items, add quick drop functions, add templates, add quick drop shortcuts, add glyphs for the icon edtor, and do all kinds of things.  

 

This should be enough reasons for the paid version of VIPM.

My boss is trying to save money by creating installers for code reuse

But how do other developers know if more code has been added to the reuse library? Is it notified through team meetings?

[LogMAN]

My boss is trying to save money by creating installers for code reuse

 

Stupid boss

In a time before VIPM, an installer (or in my case a solid zip file) used to be a good solution, however since a couple of VIPM versions the feature to create packages is available even with the community version. Also still working is the OpenG package builder (however I recommend VIPM). Just try it, it works like a charm (but keep in mind: there are certain limitations because of the license).

 

But how do other developers know if more code has been added to the reuse library? Is it notified through team meetings?

If you want to automate the process of updates you should get a license for VIPM and setup your own repository. Once you publish a new version everybody who is registered (also requires license) will see a * on the package. In terms of cost, the time spend to tell everybody that an update is available (meeting, or sending mail with everybody copy-pasting files) vs. sending a mail and everybody clicking 'update' in VIPM should be considered (again the VIPM solution is solid and tends to work where a manual task causes issues that could be avoided).

 

In my case we send mails with a link to the new *.vip file, so it is only a matter of a couple of clicks. 

[ShaunR]

My boss is trying to save money by creating installers for code reuse

 

Installers are probably the worst option for toolkits/reusable code within a company. Sure if you are going to distribute to third parties it warrants the extra effort, but internally it just adds more overhead for pretty much everything (coding, testing and documentation) as well as causing all sorts of problems with version control. It has few, if any, benefits.

 

A far superior solution (and generally free) is to use your favourite flavour of source code control for distribution from a central server. It does come with some caveats, but it is infinitely better and more flexible than installers.