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

[Akiel]

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...

[crossrulz]

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

---

[User002]

---

@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

[Akiel]

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

[crossrulz]

---

@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.

[Akiel]

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

[User002]

---

@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

[SteveChandler]

---

@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.

[SteveChandler]

<Double posted somehow>

[User002]

---

@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