Source code control question

[WavePacket]

Hi guys,

I'm not entirely sure where I should pose this question, but I've got a quick question about how to do source code control when developing multiple libraries. 

Lets say I develop many libraries, and incorporate these in many projects. All libraries and projects are git repoed. 

Normally in my project folders, I just reference the library. That way whenever I open my project, it automatically pull in the newest version of the library. My question is when I don't want to do that, and I want to "freeze" a library on an older version and only include that version of the library in my main project. (This is to maintain stability of the library.) Is the correct way to that to duplicate the library files into the directory of the project, and then just include that frozen copy of the library into the source control of the project?

Not really sure what's best practice here. Occasionally I have a need to be able to open up a previous version of the source files, and edit an old version without pulling in all the newest versions of the associated libraries.

Thanks for any help,

-Wavepacket

[billko]

I think the real solution is to make distributions of libraries so your code can reference the version it needs.

[tyk007]

100% agree with Bill.

VI Packages used to be the cool thing (well, I still use them) to create versioned components for the development environment. Typically I'd put common components like this into their own repo, so that they can be developed and versioned discretely. Then, when I need use of one, I'd copy the package into a "Dependencies" folder in my project so other devs know which version the source requires (along with documentation stating that, of course).

You can do similar things with NI Package Manager but my experience with it is a lot less. 

[crossrulz]

My solution is to have a project for my reuse libraries and I build them into Packed Project Libraries (PPLs).  I then copy the PPLs into the projects that need them.

I know others who would use subprojects in GIT.

[Yamaeda]

I would keep each library in a folder of it's own and use GIT to freeze that folder to a specific ID or label. If you need to use an old one you can easily do a Switch and update to change the code version.

[FireFist-Redhawk]

VIPM is another way to make versioned distributions of your libraries, it also can put them into the palettes for easier use. Unfortunately a lot of the really cool stuff requires the paid version of VIPM, but the free features are certainly enough to get a decent toolkit made. Spend some time learning how to make packages in VIPM and you'll be glad you did:

Spoiler

[WavePacket]

---

@billko wrote:

I think the real solution is to make distributions of libraries so your code can reference the version it needs.

---

I'm still learning. Is "source distribution" (link here) what you are referencing? 

[WavePacket]

---

@crossrulz wrote:

My solution is to have a project for my reuse libraries and I build them into Packed Project Libraries (PPLs).  I then copy the PPLs into the projects that need them.

I know others who would use subprojects in GIT.

---

So I was reading about this yesterday, and crept across an apparent issue that PPLs can't include malleable vis? Is that true? Some of my general purpose libraries have .vims, so my understanding right now is that I can't act on my need with PPLs. Maybe my understanding of PPLs isn't right though...

[Yamaeda]

---

@WavePacket wrote:

---

@crossrulz wrote:

My solution is to have a project for my reuse libraries and I build them into Packed Project Libraries (PPLs).  I then copy the PPLs into the projects that need them.

I know others who would use subprojects in GIT.

---

So I was reading about this yesterday, and crept across an apparent issue that PPLs can't include malleable vis? Is that true? Some of my general purpose libraries have .vims, so my understanding right now is that I can't act on my need with PPLs. Maybe my understanding of PPLs isn't right though...

---

I think the issue was that the top VI couldn't include it, but it's easy enough to try and build one. 🙂 VIM's are 'new' by LV standard, so somehow that test wasn't included in the verification process, it seems.

[WavePacket]

---

@Yamaeda wrote:

I would keep each library in a folder of it's own and use GIT to freeze that folder to a specific ID or label. If you need to use an old one you can easily do a Switch and update to change the code version.

---

I'm thinking though the mechanics of this suggestion.

Let's say I've got project P which includes library L. P & L are in separate repos. My workflow is often that I'm simultaneously working on many projects, and L, somewhat organically. Occasionally P gets to a specific version (let's label this version p_lts) which is released as a long term support, and it requires a specific version of L (labeled l_lts). P & L then progress organically to newer versions.

So someday I'll need to edit p_lts and l_lts even though they aren't the most recent versions. If P & L are separate git repos, then if I rollback P to p_lts, there isn't a "built" in tool which will recall L to l_lts.

Do I separately maintain that record (word doc, for example) of what version to rollback L too?