LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What’s the best way of distributing code to a new dev pc?

For a new dev PC I would use a source control product (Im using subversion but most will do the job) to place the latest code on the new pc in the correct directory, every sorted and under control. The hard part is finding a source control product that interfaces with labview nicely but thats another discussion...

Please remember to accept any solutions and give kudos, Thanks


LV 8.6.1, LV2010,LV2011SP1, FPGA, Win7
Message 11 of 36
(712 Views)

If you actually read the original problem, you will see that the source control did not solve the problem.  Source control cannot manage dependencies like what the OP needed.  VIPM is a tool to help with this.


@User002 wrote:

@SteveChandler wrote:

VIPM is not source control. It is an entirely different animal.


Ah, yes, of course. Another advantage for GIT/Mercurial that can act as both. 

 

Br,

 

/Roger

 


 


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 12 of 36
(708 Views)

@crossrulz wrote:

If you actually read the original problem, you will see that the source control did not solve the problem.  Source control cannot manage dependencies like what the OP needed.  VIPM is a tool to help with this.


If you paint yourself into a corner with dependencies to half-baked external tools. Well, bad things happen!

 

Br,

 

/Roger

 

0 Kudos
Message 13 of 36
(705 Views)

Thank you for the polite reply

 

Never had a problem with dependancies that couldnt be managed with source control, it may not evaluate them but thats not its purpose

Please remember to accept any solutions and give kudos, Thanks


LV 8.6.1, LV2010,LV2011SP1, FPGA, Win7
Message 14 of 36
(702 Views)

@User002 wrote:
Man am I happy about the simplicity of a clean vanilla LabVIEW installation with only GIT and Mercurial as a code distribution and version control back end.

You must also like rewriting code for every program.  Or copying code from another program and break stuff because code from project A is somehow pointing to code in project B and then it's a mess to clean up.

 

Trust me, a reuse library is one of the best things you can invest in.  And when you have multiple versions of LabVIEW you have to work in, I'd like to see GIT handle that library for all of the versions.  That's where VIPM gets its usefulness.


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 15 of 36
(700 Views)

Ah didnt get on with git /mercurial for a number of reasons leading to loss of control between our team.

 

Not rewriting much but then we do many one offs that are not normally similar enough to re-use (mores the pity) but will keep vipm in mind if things go that way I do have a library of common functions tho so will investigate if its worth implementing here.

 

Thanks

Please remember to accept any solutions and give kudos, Thanks


LV 8.6.1, LV2010,LV2011SP1, FPGA, Win7
0 Kudos
Message 16 of 36
(697 Views)

@crossrulz wrote:

@User002 wrote:
Man am I happy about the simplicity of a clean vanilla LabVIEW installation with only GIT and Mercurial as a code distribution and version control back end.

You must also like rewriting code for every program.  Or copying code from another program and break stuff because code from project A is somehow pointing to code in project B and then it's a mess to clean up.

 

1: Trust me, a reuse library is one of the best things you can invest in.  And when you have multiple versions of LabVIEW you have to work in, 2: I'd like to see GIT handle that library for all of the versions.  That's where VIPM gets its usefulness.


  1. I know. For example: (http://gitorious.org/labqt/labqt/trees/master https://decibel.ni.com/content/people/RogerIsaksson?view=documents)
  2. Yes, it is called a branch.

Br,

 

/Roger

 

0 Kudos
Message 17 of 36
(696 Views)

@User002 wrote:

@SteveChandler wrote:

GIT and Mercurial do not do VI Package Management. They do not have LabVIEW pallette editors or dependency checking. They do not connect to the tools network and there are no VI Package Configurations.


Man am I happy about the simplicity of a clean vanilla LabVIEW installation with only GIT and Mercurial as a code distribution and version control back end.

 

Less is more.

 

Br,

 

/Roger

 

 


Again, VIPM has nothing to do with source control. You absolutely do not need to use it. I use it because it simplifies package management and because there are a lot of tools out there that you need VIPM to install.

 

VIPM is for stuff that goes into vi.lib. It is code that a developer will use and not edit. It is not meant for distributing a project to another development machine that will be working on that project. If you do not create "reuse code" then you do not need  the package builder. Regardless of that, VIPM is the tool that you need to install reuse code such as OpenG. It is to LabVIEW what RPM is to Linux.

=====================
LabVIEW 2012


0 Kudos
Message 18 of 36
(695 Views)
<Double posted somehow>
=====================
LabVIEW 2012


0 Kudos
Message 19 of 36
(695 Views)

@Akiel wrote:

Ah didnt get on with git /mercurial for a number of reasons leading to loss of control between our team.

 

Not rewriting much but then we do many one offs that are not normally similar enough to re-use (mores the pity) but will keep vipm in mind if things go that way I do have a library of common functions tho so will investigate if its worth implementing here.

 

Thanks


The drawback with distributed source control is that it can be quite challengeing for a starters, specially if you have been working with centralised systems such as Perforce, SVN, Clear Case, etc..

 

Nowadays when it's possible to separate the source from the binary in LV, it makes much more sense to scrap VIPM. I don't have any dirty stars as I GIT commit/push/pull between my systems thanks to this.

 

Br,

 

/Roger

 

0 Kudos
Message 20 of 36
(690 Views)