Manage group of people with GitLab

[Konan__]

Hi,

I've started experimenting Git (and GitLab as repository and issue tracker).

I will be an "architect", that is I will lay down the structure of the test software, then a couple of collegues will help in "filling the blanks".

By "filling the blanks" I mean from simple things (like "I give you the terminals and front panel and you do the block diagram of this subVI"), to a bit more complex things (like "implement feature X", or "fix bug Y").

I will also develop in parallel.

The only sane way I know to manage all this is with Git/Gitlab,

I already set up and it's working quite good, but the most problematic thing is the "three-way merge", that is a merge that is not a "fast forward" but actually you need to PICK and MODIFY.

I've found that many files get modified, from the trivial .lvlps or .alias to other obscure things, expecially when CLASSES are involved, and internal properties of the Vis, for example a Vi that you put as a class method knows that it is part of that class, if you change the class or something, things can mess up pretty quickly.

Do you have any experience in this, also with actor framework? AF generate many files and classes, and I am afraid I can't manage this with LabVIEW.

LV is mostly binary, and I am not able to use git successfully at full power with confidence.

thanks for any feedback

[cbutcher]

Hi!

A couple of quick things to check first (numbered so easier to reference):

1. Did you "Remove compiled code"? This is really important for sanity with Git and LabVIEW
2. Add .aliases and .lvlps to .gitignore (they're computer specific and autogenerated)
3. If you're doing the first task (I made the FP, you make the BD) then this implies you already added the files to the project/library. In this case, only the VI should be modified (given point 1) so it's much simpler.
4. If you're doing the second task (implement X) then probably you'll modify the project/library/class files. You can *sometimes* allow git to merge this, but it will sometimes clobber them. I'd definitely avoid merging the class files (but with 2017 I've had reasonable luck with lvproj files... YMMV). In this case, you can use something like 
   • git merge (oops - conflicting files A.lvproj)
   • git checkout --theirs A.lvproj
   • Open the project, check the files. Alternatively, use a text editor or the diff utility (git diff with no diff driver is good here) to get an idea what changed.
   • git checkout --ours A.lvproj
   • Repeat the previous idea - check the files. Decide which is closer to the desired final state.
   • git checkout --ours or git checkout --theirs (pick the closer) A.lvproj
   • Open the project, use the Add dialog to readd any files that are missing (possibly error prone - checking the Dependencies list can help you find things you missed from the project here).
   • git add A.lvproj
   • git commit (I think. I think --continue is for rebasing, not merging). Set your message and away you go!
5. No special comments for Actor Framework 🙂

[Oli_Wachno]

First of all, GIT (or any other SCC) is not meant for "managing people"

I am still no expert on GIT yet still this old fashioned SVN guy, yet my suggestion to oragnize your project workflow is to

1.) Design a robust project structure using LVLIBS with planned dependencies

2.) Assign responsibilities for the libraries to dedicated people.

3.) Make sure you have a regular communication in place, where team members can discuss needed modifications to modules (outside "their" resonsibility)

You can get even more, if you are using a decent amount of decoupling and abstract classes. The SCC will add a tremendous degree of traceability and robustness to the project workflow.

[cbutcher]

Your question makes it sound like you have VIDiff and VIMerge set up successfully already, but if not, I strongly recommend this tool: https://github.com/smithed/vicompare

(Actually, I recommend it even if you already have something else working, unless you're using this or something equivalent).

A significant benefit is the ability to use `git diff` with no arguments, because it launches an executable which blocks until you close it, preventing the seemingly default behaviour of opening VIDiff for the first VI with a change, then almost immediately replacing it with the second, and so on...

[Konan__]

1. YES

2. YES

I didn't have problems when the merge is a "fast forward", but that is only ideal. I pratice every merge will be problematic.

If you manage the project with github/gitlab you have to create an "issue" for a feature or bug. Then you create a branch named "feature-n" or "bugfix-n", and start doing your work, that is at least 1 commit on that branch.

MEANTIME, other people will make other branches (from master), to do other stuffs.

At some point (say wednesday) I merge one of these branches into master, because it's OK.

So later when other branches want to be merged ("merge request") and you start having the "three-way merge" where it's more complex

PS: I don't use git to manage people, but GitLab/GitHub/AzureDevOps ARE tools to manage people and projects, actually they are the best tool to do Agile Programming / Lean Programming. If you are doing differently, you are doing it wrong 🙂

I think that "give each people responsability over a module" is totally wrong today. Every member could modify/branch/test whatever. That's the productivity gains you have with these modern Lean Programming Platforms.

[cbutcher]

So for that situation (I think either the same as, or similar to, "gitflow" workflow), you want to be using the rebase functionality before trying to merge.

That way, when you actually do merge, it's a ff-only merge.

The logic behind the rebase is largely the same. As Oli mentioned, if you separate out responsibilities a bit, the chance of multiple incompatible changes to the same file is significantly reduced. Having smaller files (like in some cases as promoted by AF) also helps here.

The VIMerge tool can (although I think the UI is pretty hard work) be used to carry out merges.

I do whatever I can to avoid this, down to using git diff on the VIs, copying the changes to the clipboard, and then using the checkout --{ours,theirs} file.VI and pasting directly, then modifying in place.

[Oli_Wachno]

---

[...]

I think that "give each people responsability over a module" is totally wrong today. Every member could modify/branch/test whatever. That's the productivity gains you have with these modern Lean Programming Platforms.

---

Maybe the term responsibility for a module is a bit overstated, point given.

I am a big fan of lean and agile, yet I have seen enough interpretations of this concept(s) which have lead to a "programming anarchy" in fact being a roadblock for productivity: the number of merge requests increase finally leading to only half-hearted processing of those.

But.... different approach, different discussion.

[Taggart]

---

@Konan__ wrote:

If you are doing differently, you are doing it wrong 🙂

I think that "give each people responsability over a module" is totally wrong today. Every member could modify/branch/test whatever. That's the productivity gains you have with these modern Lean Programming Platforms.

---

I always find it funny when the guy asking for advice tries to tell everyone else they are doing it wrong.

You may be able to get away with multiple people working on the files in some text-based languages but in LabVIEW, it just doesn't work that way.  Been there.  Tried that. And ended up exactly where you are.

The simple answer to merging in LabVIEW is one word: Don't.

[p4keal]

I would like to make some remarks. Separate compiled code setting in project settings applies only to new VIs. If your project has a history before Git, you can use the button "Mark Existing Items ..." to check if the setting applies to all VIs.

Maybe that's obvious, but I've had headaches for years with Git and LabVIEW because I did not know this future.

For large projects, splitting into submodules is highly recommended. But keep the submodules hierarchy flat! Otherwise, diamond like dependencies will lead to chaos!
Default setting for submodule folder should be read only (in Windows Explorer, right-click submodule folder -> Git Bash here, enter chmod -w -R . )

In LV -> Tools -> Options -> Environment activate "Treat read-only VIs as locked" and "Do not save automatic changes".
Often You will want to copy code from a read-only VI. LV opens there in running mode. You can leave this mode and allow copying with Ctrl + M.

As windows git client I use TortoiseGit, because it integrates well in Windows Explorer. But for intensive usage of Submodules I think Atlassian Sourcetree is better.

If You have to change one of the submodules keep in mind to commit and to push it to GilLab, before You push your main project changes.

[FabiolaDelaCueva]

We have posted some articles for Source Code Control at delacor.com/category/scc/

You might get some pointers on the article about how to organize your libraries into repositories and then package them to be used in the main project. We have found that this minimizes the need for merge and keeps better track of what is considered "released" code.