How does version control with LabVIEW VIs work?

[Terry_ALE]

---

@billko wrote:

That being said, it's never a good idea to have multiple devs working in the same LabVIEW project!

---

If properly designed and modularized (use of classes and/or lvlibs), you can have multiple people on the same project.

[billko]

---

@Terry_ALE wrote:

---

@billko wrote:

That being said, it's never a good idea to have multiple devs working in the same LabVIEW project!

---

If properly designed and modularized (use of classes and/or lvlibs), you can have multiple people on the same project.

---

I'm not sure if we are talking about the same thing.  By "project", I am referring to a literal LabVIEW project, as defined by the lvproj file.  To me, it's always pretty dangerous to be working inside that definition of a LabVIEW project.  The team has to be very disciplined to make it work.

[Terry_ALE]

Then we agree.

We allow for only one person to change the project file specifically when we add lvlibs, classes, target settings, and build specifications. With no other files owned by the project it reduces the amount of changes to the project file

[wiebe@CARYA]

---

@billko wrote:

---

@Terry_ALE wrote:

---

@billko wrote:

That being said, it's never a good idea to have multiple devs working in the same LabVIEW project!

---

If properly designed and modularized (use of classes and/or lvlibs), you can have multiple people on the same project.

---

I'm not sure if we are talking about the same thing.  By "project", I am referring to a literal LabVIEW project, as defined by the lvproj file.  To me, it's always pretty dangerous to be working inside that definition of a LabVIEW project.  The team has to be very disciplined to make it work.

---

I guess we're very disciplined then .

Never put much effort in it though. With auto populating folders, we simply started working on separate parts. When there was a conflict, ask the other if they changed it deliberately. Then pick theirs or mine, problem solved. This was even without separate compiled code.

Of course decoupled code helps a lot.

Working with multiple people isn't a good idea. But if you need a 2 FTE year project to be done in .5 years, you have to. Just remember that it's not as easy as 2/.5 = 4. There will be overhead. Maybe even more then 50%, so you'd require 6-8 people, spending maybe 4 FTE years iso 2 FTE years, just to get it finished.

[Norbert_B]

---

wiebe@CARYA wrote:
[...]

Working with multiple people isn't a good idea. [...]

---

I wouldn't be that strikt. However, working with multiple developers in a single project (not to be confused with "single LV project file"!) requires structured processes IN EVERY PROGRAMMING LANGUAGE. Those processes are described and proposed by what is called Software Engineering.

LV adds some additional obstacles because of the proprietary binary file formats, but that 'overhead' is small compared to what you should already incorporate suggested by software engineering.

Conclusion: If your team defines and follows processes with disciplin, team development is pretty well to handle.

This post already contains multiple recommendations for team development so read all posts with care if you really want to have those recommendations at hand!

[wiebe@CARYA]

---

@Norbert_B wrote:

---

wiebe@CARYA wrote:
[...]

Working with multiple people isn't a good idea. [...]

---

I wouldn't be that strikt.

---

I wasn't strict, probably should have added a or .

Working with multiple people is something that is simply necessary. Sometimes even desirable. When it is, you need to do it right. That is, you need to do a few things right, and you need to not do a few things wrong. Mostly common sense though, but if you're all new to LabVIEW, I'd recommend getting some experience first.

Before SCC (before we started using it), we needed to work together sometimes. We did this over a network share. That was way worse then SCC. We still managed to get things done.