PDA

View Full Version : Git and Global Packages



sjwalter
1-Jun-2022, 04:43 PM
We are planning to move our development to Git for a team of three developers and using GitHub as the location of our remote repositories.

Currently, we have a different workspace for each part of our product in the form of
Workspace A
-- Workspace Folders (AppSrc, AppHTML, Data, DDSrc, IDESrc, etc.)
Workspace B
-- Workspace Folders
GlobalPackages (.pkg and other files shared by all workspaces)
GlobalBitmaps (icons and bitmaps shared by all workspaces)

The config.ws file in the Workspace A programs folder contains


AppSrcPath=.\AppSrc;..\GlobalPackages
BitmapPath=.\Bitmaps;..\GlobalBitmaps

My thinking for Git is that Workspace A would be a repository of it's own, as well as Workspace B. But, how do I include the two global folders as part of the repository? I've seen mention of adding them as submodules, but I've also read that this can be quite cumbersome to manage.

What is the best way to manage global folders in a Git environment?

Steve
USA Software, Inc.

Samuel Pizarro
1-Jun-2022, 08:33 PM
All my libs and global stuff like that resides in their own/separete git-repository. totally independent of the main wokspaces..

But that's how I've decide to handle it.. I think it's just a matter of prefference.

Michael Mullan
2-Jun-2022, 06:09 AM
you can keep them in separate repositories, but you should really "tag" all the repositories with the same version number as you release a product, because you need to be able to go back to exactly what was compiled if you're hunting bugs in the earlier revisions.

Dennis Piccioni
2-Jun-2022, 10:00 AM
I agree with Samuel and Michael.

sjwalter
2-Jun-2022, 10:09 AM
you can keep them in separate repositories, but you should really "tag" all the repositories with the same version number as you release a product, because you need to be able to go back to exactly what was compiled if you're hunting bugs in the earlier revisions.

Another case of needing uninvolved eyes to look at the situation anew. Didn't even consider that as a possibility!

Yes, version tagging is a big part of this process. This whole thing is going to require a new way of thinking that I'm sure I'll get push-back on at first. But, once they realize the benefits, I'm hopeful they'll be on board. I get real tired of having to re-do work because someone overwrote code.

Thanks for the input, everyone!

Steve
USA Software, Inc.

Marco
2-Jun-2022, 12:54 PM
The designed way to deal with that is using git sub modules.
Depending on your UI it is easier or harder to implement, but basically it stores the commit point of each library into your main repo, so they are always switched back to what they were. No need for manual labelling for that purpose.

Ola Eldoy
9-Jun-2022, 07:55 AM
Hi all! I'm doing a "hit & run" on the forums today - and am using the opportunity to add a comment here...

Using Git submodules can work well, but note that it comes with a learning curve and a bit of added complexity to your workflow.

If I could choose my optimal solution it would be a "DevOps centric Continuous Delivery" setup where pushes to the release branch for all repositories are automatically deployed to a staging environment for further automatic and/or manual approval steps and then a deploy to production (either manual or automatic). Then versioning is "simply" a matter of deployment history from your CI/CD tool.

Michael Mullan
9-Jun-2022, 08:31 AM
That's what we do.

/MM