Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (6)

Resolved Git, PowerBuilder, and the Real World?

  1. Advice
1
Votes
Undo
  1. Christopher Craft
    Christopher Craft
  2. PowerBuilder
  3. Tuesday, 29 March 2022 00:34 AM UTC

With more developers working from home we have begun the transition of moving off our 'traditional' source control system to Git because of the remote advantages it has. As we begin to go down this path I am finding myself questioning how large companies with a lot of developers are able to manage the 'complexities' of PowerBuilder...the DataWindow...when multiple developers could be modifying the same object.  In my mind, merging a DataWindow is the very last thing you want to do (and I would go as far as shouldn't do).  Since you now have no 'Checking out' of objects it seems like this opens the door to so many more conflicts.

I am so use to checking objects out and organizing my coding life that way it becomes difficult to see the advantages of Git in a multi-developer environment.  The main production team will work on multiple features, enhancements, etc at the same time and not having visibility to this seems odd to me.

Anyway, without going into too much detail I was hoping to get some real world feedback with some of you that might be using it with multiple developers.

Thanks for your input.

Chris Craft

Issue with barcodes using pdfdocument
window.webBrowser.postMessage()  not work. 
Responses (6)
Tobias Roth
Tobias Roth Accepted Answer Pending Moderation
  1. Saturday, 2 April 2022 13:42 PM UTC
  2. PowerBuilder
  3. # 1

Hi Chris,

we have been using PB with git in conjunction with GitLab for four years now.
We have a main development branch and always a release branch that corresponds to the current production version.
Within the main development branch, we work with simple feature branches and merge them with the main branch using a GitLab MergeRequest.

Changes in our release version are also implemented via feature branches, which are based on the release version.
The merge is done via two merge requests in GitLab:

Main and Release branches are protected branches in GitLab. 
If there are conflicts in the MergeRequest, these are resolved locally by merging the the main or release branch into feature branch.
After pushing the resolved conflict to the remote repo, the MergeRequest can be merged in GitLab.

To ensure that merging without conflicts using Git tools such as GitLab, TortoiseGit and Sourcetree works without PBL binary conflicts, we decided not to save the workspace's PBLs directly in Git, but to save them in a separate folder in the repository.
The workspace PBLs in the root are excluded via a .gitignore file with the entry "/*.pbl".

The git pull works for us in three steps:
1. git clone
2. Copy PBLs to the root directory
3. PB object refresh.

We generally resolve conflicts outside of the IDE with a subsequent refresh in the IDE.

Under certain circumstances code blocks are moved when editing DWs or when changing function parameters. This can complicate a Git Diff or the review process in GitLab MergeRequests. We have already created tickets for this at Appeon:

In general, we've been doing quite well with our Git/GitLab concept for a number of years.
We don't use the GitLab lock function.

I hope this will help you.

Regards Tobi 

 
Comment
Load more comments
Tobias Roth
  1. Tobias Roth
  2. Wednesday, 6 April 2022 05:32 AM UTC
the comparison was made a few years ago, of course a lot could have changed in the meantime.

We chose GitLab because of the very good CICD functions.

As far as I know, neither GitLab nor GitHub currently offers any advantages specifically for PB.

For GitLab I am currently considering adding syntax highlighting to power builder in the internal editors.
  1. Helpful
Carl Bolduc
  1. Carl Bolduc
  2. Thursday, 4 January 2024 18:17 PM UTC
Hi Tobias, regarding this part of your process:

----------

To ensure that merging without conflicts using Git tools such as GitLab, TortoiseGit and Sourcetree works without PBL binary conflicts, we decided not to save the workspace's PBLs directly in Git, but to save them in a separate folder in the repository.

----------

Can you provide more details of how you do this? If the pbl files are ignored, how to you manage them in a separate folder in the repository?
  1. Helpful
Tobias Roth
  1. Tobias Roth
  2. Monday, 29 January 2024 20:36 PM UTC
Hi Carl,

sorry for the late reply.

We have decided to store the PBLs outside of Git.

For each automated build via Gitlab Pipeline, we save all PBLs as a ZIP file to a network drive with the current commit-sha as the file name. The files are then extracted during the next build and used for the compile.

A practical side effect is that we can retrieve cleanly compiled PBLs at any time and insert them into the local workspace.

We exclude *.pbls via .gitignore.

We have been using this method for about 4-5 years now without any problems.

Regards Tobi
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 29 March 2022 00:46 AM UTC
  2. PowerBuilder
  3. # 2

Hi Chris, Check out the PB roadmap under the "Dev Productivity" section.  We are doing enhancement in how PB source code is version controlled to mitigate conflicts.  In the meantime, another thing to consider is using a version of Git that supports locking.  Some Git implementations do support this. 

Comment
Load more comments
Christopher Craft
  1. Christopher Craft
  2. Tuesday, 29 March 2022 21:57 PM UTC
But if someone does implement Git locking then it would be a great feature for PB to have those options show in the IDE. Best of both worlds and people will flock to using PowerBuilder!! :-)
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Friday, 1 April 2022 14:48 PM UTC
Our product management team will revisit this topic, but no promises. ;-)
  1. Helpful
Roland Smith
  1. Roland Smith
  2. Monday, 29 January 2024 21:57 PM UTC
What about changing the layout of DataWindow object source to make it easier to Compare/Merge? Have any settings that are default not appear in the source.
  1. Helpful 2
There are no comments made yet.
Matt Balent
Matt Balent Accepted Answer Pending Moderation
  1. Tuesday, 29 March 2022 11:25 AM UTC
  2. PowerBuilder
  3. # 3

Great question Chris!  We've encountered these issues with a relatively small team (3 devs) on my current project.  What I've been doing is exporting objects prior to me making any changes.  This way I can compare and isolate my changes as well as any other devs changes and more easily merge them manually. (I find code compares within PB to be very poor with Git in PB).

The merging within Git has had mixed results for me - at times stuff gets put into the branch with a bunch of 'HEAD' and '>>>' type crap in it which of course won't compile within PB - leading to a whole new mess of errors/constant migration notices/etc.

So my work flow is roughly:

Ask team if they are modifying an object.  If Yes then:

Pull objects

Export object to 'original' folder

Make my changes

Export object to 'changed' folder

Revert back to original code by importing the beginning import over my changes.

Do the Refresh and Pull to get the new code.

Export and compare the new against my 'changed' export to identify and merge my changes.

Commit and Push

 

...remember fondly the TFS days when this just wasn't an issue...

Comment
Load more comments
Benjamin Gaesslein
  1. Benjamin Gaesslein
  2. Friday, 1 April 2022 06:25 AM UTC
I'd say if you work with git it is absolutely imperative that you know how it works. If you don't know the commands, learn them. There's plenty of material available for free. The pro git book is available online https://git-scm.com/book/en/v2 , if you prefer a more practical approach there's https://learngitbranching.js.org/



In the vast majority of cases, git merges files automatically. A conflict happens whenever the same line was changed in both parent commits. In these cases, git inserts what you call "'HEAD' and '>>>' type crap" into the file to indicate which change was done in which commit. You can either figure it out by hand or use a conflict editor, which translates these into a side-by-side view. You have to decide which change to keep or how to combine them. I usually use TortoisGitMerge for this. Once all conflicts are resolved you can continue the merge. Your local branch is now done and yes, you have to push it to the remote repo to update that. Why would it report another conflict? There's no need to import or export anything. If your PB workspace is set-up correctly you have a "ws_objects" folder that contains every source file tracked in git. Like I said, the only PB command you really need is "Refresh", which loads the current code from ws_objects into the actual PBLs.

But this is beyond the scope of this forum. I would suggest investing some time into learning how to use git.
  1. Helpful 1
Matt Balent
  1. Matt Balent
  2. Friday, 1 April 2022 12:17 PM UTC
>>>difficult to see the advantages of Git in a multi-developer environment<<<

This is the crux of the issue.
  1. Helpful
Matt Balent
  1. Matt Balent
  2. Friday, 1 April 2022 14:55 PM UTC
Perhaps a better approach would be to have a 'Git Guru' do a tech article on how to use it with PB. If I read your response correctly Ben, you are stating "only use Refresh within PB" then how do I do the other things from the command line? If we were speaking of simple text files, like database scripts, doing the command line thing is easy. What about the .pbl files? They are being constantly listed as changed and needing to be committed and pushed. Do I ignore them? Should I add them to the .ignore file? There are also inconsistencies in Git when I commit and then push changes. Example, I change a single script. Do a refresh, do a Pull. do a commit (one item is shown in a treeview with a prompt for comments), commit is successful, do a Push - now git reports "Pushing current object: 5, total objects: 5" ...hmm what are the other 4 objects? I have no clue what just happened...
  1. Helpful
There are no comments made yet.
mike S
mike S Accepted Answer Pending Moderation
  1. Tuesday, 29 March 2022 13:24 PM UTC
  2. PowerBuilder
  3. # 4

In your transition off your old SCC, did you migrate your SCC history or just start 'fresh'?

 

having that history is so valuable to me

Comment
Christopher Craft
  1. Christopher Craft
  2. Tuesday, 29 March 2022 15:19 PM UTC
The first team to go operates very differently than our ERP product team so the history is not as important but, in the past when we moved systems we would just keep the old system around and go back to it if we needed to compare. It is a pain in the beginning but you get down the road far enough where it starts to not matter.
  1. Helpful 1
There are no comments made yet.
Christopher Craft
Christopher Craft Accepted Answer Pending Moderation
  1. Friday, 1 April 2022 14:38 PM UTC
  2. PowerBuilder
  3. # 5

So what do you all do when you have multiple features that you are working on for a particular Release?

In my current source control we have things called a Change Request (CR).  For each CR we create task(s) and then check out our code to that.  I will have multiple CR's for the same release (ie. Release 10.0.0.0).  I currently can work on all the CR's in my local work area and complete them one at a time. 

With Git would you create branches for each CR in order to separate each feature or do you just do all the work in one branch?

Comment
There are no comments made yet.
Yakov Werde
Yakov Werde Accepted Answer Pending Moderation
  1. Friday, 13 May 2022 11:43 AM UTC
  2. PowerBuilder
  3. # 6

Years back there was a non-documented "internal" feature that saved DW Syntax as XML.  This was actually implemented internally in PB .NET where they changed the GetFullState / SetFullState (getChanges, setChanges) blob contents from flat text string to XML string.  I discovered this when attempting to integrate PB.NET clients with PB Classic EAServer components. The integration bombed because engineering silently changed BLOB structure on the PB .NET side.

 

My point. Have DWSyntax as XML would simplify DW Diff and Merge. Changes would be almost human discernable and a generic Diff tool could clearly point out changes

 

Yakov

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.