Using Git with Pick Basic ERP running on Rocket D3

[Peter Lettieri]

Hi Group,

I'm looking to sync my current code base with Git, as I'm planning to have additional programmers start working on and documenting my ERP application.  

Is there a package or module that would sync code changes with Git?

Thanks,

Pete

[Doug Averch]

Using Eclipse IDE you can access GIT through our XLr8Editor for D3.

See the U2logic Editor Tool link.

Regards,

Doug Averch (CTO & Owner)

www.u2logic.com

[Wols Lists]

How well do you know git? I don't quite know what you're getting at ...

If you mean you have a dev system and a live system, I'd set up a third,
bare repository system, and then you can push changes from the dev
system then pull them down onto the live system.

If that's not what you mean, can you clarify?

Cheers,
Wol

[Peter Lettieri]

I've never used git with a pick filesystem and am familiar but not an expert.

I have a dev system and a live system but we do all of our development on the live system.  The dev is more of a mirror.

We build modules, release them to a beta screen, do our testing and debugging, then archive the old version and upload.

Our programmer is very good and has been doing this for 40+ years, and I'm looking to bring on some new devs to work with us, but am trying to find the best way to control versioning and track changes.

Thanks Wol for reaching out.

[Wol]

On 17/11/2022 20:36, Peter Lettieri wrote:
> I've never used git with a pick filesystem and am familiar but not an
> expert.
>
> I have a dev system and a live system but we do all of our development
> on the live system.  The dev is more of a mirror.
>
> We build modules, release them to a beta screen, do our testing and
> debugging, then archive the old version and upload.
>
> Our programmer is very good and has been doing this for 40+ years, and
> I'm looking to bring on some new devs to work with us, but am trying to
> find the best way to control versioning and track changes.
>
> Thanks Wol for reaching out.
>

Hmmm

I'd be inclined to do all the testing on (multiple) dev systems. I'm
actually in the nice position of trying to introduce ScarletDME to my
employer, so I'm thinking hard about the best way to keep on top of things.

I'm writing a little utilty that dumps/loads a dictionary to a text
file. I'm trying to lay out a file structure that works for what I think
the setup is.

My angle is going to be "this is a tool to replace Excel". The trouble
is I'm up against Google BigQuery - the company won't appreciate me
bringing in another database, so I need to promote it.

But the first thing you need to do is work out how you are going to get
your current structure into git. I think you need to ask "where is the
root of our live data", and more importantly make sure that layout works
for you. Then you can dump all your code and dictionaries into git.

Then each of your developers needs a copy of the live environment to do
their development in, so they can test it, and then push it to live.
Developing in the live area is NOT wise.

Rather importantly, this then means that if your developers have a copy
(or partial copy) of the live system, which can then be cloned as
required, you can develop and test each enhancement in its own
development copy, push it to live, and then dump the development copy
and re-clone. And of course, if your changes go pear-shaped, just ditch
and re-clone :-)

That's the important thing - you want the developers to push their
changes to the master git repository, which you can then pull into live.
I don't think you want the live repository to be the master, it just
feels wrong to me.

Just think it through - how can you keep the developers from treading on
each others' toes, how can you push items easily to live.

I'm planning to push my directory utilities to ScarletDME, but they're
in no fit state to do that at the moment :-)

Cheers,
Wol

[Rex Gozar]

The first thing you need to do is define what is "source", what is "generated", and what is "data".

Programs are obviously "source", but what else? All dictionaries and PROC's, but also Q-pointers and file sizing parameters (so the file can be created on the target system). You may have screen and menu source items too, as well as other software configuration items, images, and shell scripts. All of these things are "source" and must be written to flat files for git to archive.

"Generated" items, like program object code, should not be saved in git, but must be reliably generated and regenerated on the target system. Compiling and cataloging programs is typically just a start; you probably generate other artifacts from your source files (e.g. create files).

"Data" isn't usually saved in git, but you should consider saving test data in another git repository. Production usage never creates 100% of the data required to test 100% of the features. That's especially true while a feature is being developed.

For our application here, I've developed my own tools to extract all our source code items into a flat-file format so they can be tracked in source code control. I can see every source code change our programmers make; a nightly process sends an email to all programmers with the latest source code diff's. Our weekly release process pulls all the source code and completely regenerates the account, creating and reloading all files and dictionaries, compiling  and cataloging all programs, and so on, so we know we have everything in source code control.

rex

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/a9514f97-b3b5-d393-facf-bbfd45d0c402%40youngman.org.uk.