Search Source by Date in gutter

[johnstagliano]

I am attempting to counter developer complaints and figure out what we need to do to change over from PDM to VS Code. And, I am running into a few PDM features that I cannot find equivalent in Code4i...

In PDM, we often use F14/F15 to order source members by change date. Is this possible in Codefori? How would we sort our source by change date. 1st in the object browser (for source files). 2nd in the IFS Browser for source code on the IFS.

In PDM, when editing a source member, we often use the F14 search and search by date. Is this possible in Codefori. How would we search the "gutter" date?

[worksofliam]

https://codefori.github.io/docs/developing/sourcedates/#source-date-filtering

[chrjorgensen]

@johnstagliano Please remember that sequence lines and source line date are attributes for IBM i source members!

IBM i source files are actually a tabel with three columns: SRCSEQ, SRCDAT and SRCDTA. This structure is unique for the IBM i platform and has served well - but now it's time to switch to the same format as every other platform: streamfiles.

IFS streamfiles are just unstructured text, separated into lines by a newline character. They have no sequence number nor source line dates.

But this is no problem, on the contrary: git will give you the line, author and time for any lines added, modified or deleted.

So streamfiles and git is much better than IBM i source members, which can't show who changed what or what was deleted.

[johnstagliano]

How will this work for our source members when we migrate them to the IFS. Do you have any recommendation on how to retain those dates.

It's not just me, we have many developers and I'm going to need to gain some level of buy in from the other developers. I see the dates on existing source being a point of contention from some of the "old school" developers.

It's easy to say git diff is better, and, it is for ongoing changes. However, it is more difficult to convince others that what they are losing will be ok in the long run.

[chrjorgensen]

Your developers seem to have to go through some pain - 'cause there are no dates in streamfiles!

From personal experience I will say, this pain is quickly over... once you see what git can do for you, you won't miss source dates anymore. It took me a week (mosyly as sys admin, not a fulltime developer), then I had forgotten all about source dates. Like switching from an ICE car to EV - in the beginning you have range anxiety, but then you get used to the EV way...

I think your biggest hurdle to to learn git and what the advantages of using git are. You will have to become acquainted with git before you migrate your code, learning git concepts like repo, branch, commit etc.. There are plenty of git courses for free on the internet, and you can simply create a directory, enter this directory, run git init and make some files and changes and commit in between. View the git log and learn that git can answer the following questions:

1. who added, changed or deleted a source line
2. when was the source line added, changed or deleted
3. which characters in the source line were changed

Source dates in members can only answer the second question and only adds and changes, not deletes.

I would recommend immediately committing any members migrated to IFS, before any changes are made, to have a baseline for the source. And mark the old source member as migrated, e.g. by inserting a line in the beginning of the member with some text like This member was migrated to IFS streamfile /dir1/dir2/file. Once a member is migrated, it should not be changed or used anymore, and all future changes and compiles must use the streamfile instead.

You get very far with git basics and git is the standard version control system in the industry. Moving to git may be hard in the beginning, but soon you will enjoy the benefits, like the rest of the world.

[johnstagliano]

We do use git for our php. And, when I developed, I developed both php and RPG. So, I used git a lot. We have both a PHP team and a RPG team. Our RPG team has not used git, so, yes that will be a learning curve. But, they will have the PHP team to help them out.

My concern is not for the changes after the files are moved to the ifs. It is for the changes prior to moving them. Not all developers are good about commenting what they changed. git will fix that as we will have commit messages and code reviews (pull requests) before the change gets merged into our development branch. But, many times we have ended up searching dates based on when a developer made a change to find what was actually changed.

My plan was when a source member is moved to the IFS/git to remove the member from the source file. But, we may need to keep an archive of those source files just for the purpose of looking at previous changes. My fear of keeping an archive is a developer might reference that rather than the current state of the source. Hopefully, no developer will try to compile from that source.

Am I missing something obvious? I sure appreciate your feedback. Do you have any opinions of keeping an archive when the source is migrated? I guess I could keep that archive on a tape backup or restrict access to that archive. That would make it difficult (but not impossible) to access the original source.

[chrjorgensen]

I would take a copy of the source files before migration starts, and store the copies in a location not accessible by the developers (by having object security implemented). That way you can always see the original source, even after migration.

If you don't do it already, I would recommend using DBGVIEW(*ALL) keyword on the compiler commands. This will store the source code and the compiler listing in the program object generated, and you will always have the source for the program, and debugging will be easier.

Sounds like you have a great plan. Having the PHP developers help the RPG developers in learn git will certainly help in an easier transition from source members to streamfiles.