Source code control question

[WavePacket]

---

@Yamaeda wrote:

---

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

---

So I did try it, and got stuck here. I thought I had to specify a top-level library, which I can't seem to do (yellow triangle). General VIs Library has .vims inside virtual folders.

[FireFist-Redhawk]

---

@WavePacket wrote:

---

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

---

I think it was already said, but work in branches! In your example, and IMO, P_lts and L_lts should exist in the master branch of your repos. When any changes need to be made, start a development branch and work in that branch. If you ever get to a L_lts (or P_lts) version 2.0, you can merge into the master branch.

[WavePacket]

---

@FireFist-Redhawk wrote:

---

@WavePacket wrote:

---

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

---

I think it was already said, but work in branches! In your example, and IMO, P_lts and L_lts should exist in the master branch of your repos. When any changes need to be made, start a development branch and work in that branch. If you ever get to a L_lts (or P_lts) version 2.0, you can merge into the master branch.

---

Yeah, Ok -- that makes sense. Thanks!

The record of exactly at which point in master the branch should start would still need to be maintained separately somehow, right?

[Yamaeda]

---

@WavePacket wrote:

The record of exactly at which point in master the branch should start would still need to be maintained separately somehow, right?

---

I haven't tried it, but you can include another repo in your project repo (in your case the library) and if so, any project checkin will also remember the library version.

Branches are a good habit, and Labels/Master branch. So, whenever you develop L, it's a new branch until you're satisfied at which point if gets merged to Master.

P uses a L label as part of its development.

[billko]

---

@WavePacket wrote:

---

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

---

Yes, that's one way.  There are a lot of good suggestions here.

[FireFist-Redhawk]

---

@WavePacket wrote:

---

The record of exactly at which point in master the branch should start would still need to be maintained separately somehow, right?

---

If you're doing well on your SCC, the branch would always start at the end of the master. Different people have different levels of SCC habits, but on the more extreme side is the idea that, nothing should ever be committed directly to the master branch. The only way the master should get updated is via a pull request after extensive testing of the new code. I do try to do that, but alas... 😅

[crossrulz]

---

@WavePacket wrote:

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

---

You can't have a public VIM in a PPL.  The reason for this is that a PPL is compiled (does not contain source code) and a VIM is technically only source code (since the inputs can be dynamic).

[WavePacket]

---

@Yamaeda wrote:

---

@WavePacket wrote:

The record of exactly at which point in master the branch should start would still need to be maintained separately somehow, right?

---

I haven't tried it, but you can include another repo in your project repo (in your case the library) and if so, any project checkin will also remember the library version.

Branches are a good habit, and Labels/Master branch. So, whenever you develop L, it's a new branch until you're satisfied at which point if gets merged to Master.

P uses a L label as part of its development.

---

Interesting, I'm definitely learning some ideal practices. Seems like what I was after is git submodules (link). From the link, "A git submodule is a record within a host git repository that points to a specific commit in another external repository. Submodules are very static and only track specific commits. Submodules do not track git refs or branches and are not automatically updated when the host repository is updated."

I'm now envisioning a workflow like this.

1. So I develop P & L in separate repos.

2. When P becomes version p_lts, in the commit for p_lts I note the commits/version numbers for l_lts. 

3. Later on, if changes are necessary p_lts - I can branch out from p_lts commit, and include a git submodule which references l_lts as a git submodule.

So if I'm understanding things, it seems that will allow me to change p_lts while including a frozen l_lts.  

[FireFist-Redhawk]

To throw one more thing at you, when you make a new Release in a repo, a zip file is created that contains all the source code at the current commit. You choose which branch to zip the contents of, at the Release creation screen.

The Git Submodules are kind of a cool feature I guess, but it seems that it's so static, it's not much different than just copy-pasting the "sub-repo" and commit ID to a text file that lives in the main repo. And also, I'm fairly sure it's going to be easier to download and unzip a file than to clone a repo at a previous commit point.

Spoiler