1. ATK Gimmy Susan
  2. PowerBuilder
  3. Tuesday, 5 November 2019 09:16 AM UTC
Good morning.
We've been using GIT for months now, but we still have problems with PBLs in a group of 10 users.
It is not clear to us how they should be treated in PB-GIT.
What is the behavior protocol for configuring POWEBUILDER+GIT?
Let me explain in detail the cases we have tried to configure.
Case 1)
-1 I load my project on the remote repo including the PBLs
-2 on each commit/push Powerbuilder sends the modified PBLs to the remote REPO (always aligned with the latest version of the pbls).
-3 The next user who pulls is an error of conflict on the pbl.
 
Case 2)
-1 Load my project on the remote repo without the PBLs
-2 I'll add in the gitignore file the exclusion .pbl
-3 Each clone user does not have PBLs locally. ( you can't find libraries immediately - PB can not work)
 
Case 3)
-1 I load my project on the remote repo including the PBLs
-2 each user executes the command ( skip-worktree )
-3 changes on pbls are ignored, but sometimes the ' skip-worktree' setting is lost. It follows that the PBLs are sent to the remote repo with all the problems of the case in the next pull.
 
In conclusion:
What are the pais in an optimal configuration for working in a group?
 
Every suggestion is welcome
 
Gimmy
Accepted Answer
ATK Gimmy Susan Accepted Answer Pending Moderation
  1. Saturday, 7 December 2019 14:27 PM UTC
  2. PowerBuilder
  3. # Permalink

Appeon send to me a patch

Comment
  1. Miguel Leeuwe
  2. Monday, 9 December 2019 02:06 AM UTC
That's great, I hope they release it also to other users with the same problem.
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Saturday, 9 November 2019 21:28 PM UTC
  2. PowerBuilder
  3. # 1

Hi Gimme,

Don't feel "endebted" as this is also for my own interest. For now, I don't have to use Git luckily, but maybe I can use it for personal projects or who knows what the future might bring, so it's good for me also to know how it works or fails.

You said: "We didn't do an 'add to source control' but we loaded the PBLs manually with 'Git add -A'.
I don't think that makes any difference."

To be honest, I'm not so sure. I think the best thing would be to make a small test project and do everything exactly as described, so no "git add -A". That's the only way you can be sure (or see what happens with the bug you've submitted).

I really hope this gets solved for you and anyone using Git.

kind regards

Comment
There are no comments made yet.
ATK Gimmy Susan Accepted Answer Pending Moderation
  1. Saturday, 9 November 2019 12:54 PM UTC
  2. PowerBuilder
  3. # 2
Wow Miguel
You spent a lot of time on my post.
I feel indebted!
Your post is clear, I have read it and reread it many times (even the user guide).
-
I make a point: When I said clone I meant a "connect to the workspace" with its refresh. (sorry for the lexical form adopted)
-
My company started with GIT many months ago, practically just made available) and the only difference I see is the upload of PBLs.
We didn't do an 'add to source control' but we loaded the PBLs manually with 'Git add -A'.
I don't think that makes any difference.
(the reason was because there was no clear iteration with: git init , git upstream ----, Etc)
To date, we have our project on AZURE (including PBLs). Seemingly everything ok.
Now our protocol says to make a "connect to the workspace" with its refresh, but the problems persist.
As you can see from the jpg attachments on the original post, there is NOT PBL upload, but in the last image ( rebase ) they appear magically.
(Precise that commit, push, pull are performed by powerbuilder and not by gittortoise, gitbash, dos, etc)
 
Detail list what has been done:
1) push a project to remote repo. ( pbl too )
2) create a gitignore file and exclude the pbl ( .pbl)
3) commit-push file gitignore
- the project is all in REPO -
4) 2 persons "connect to the workspace" and do a refresh

5) person A makes change in a source code and commit + push
6) person B makes change in a source code and pull + commit + push
7) a merge is automatically generated with the pbl inside (even if no one has sent them)
8) anyone who tries to make a pull unloads the PBLs and a conflict takes place
 
I hope I have clarified what happened.
 
Gmy
Comment
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Saturday, 9 November 2019 11:01 AM UTC
  2. PowerBuilder
  3. # 3

Hi,

I've been reading up on the use of Git:

first this one: https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/183-powerbuilder-2017-r2-new-feature-git-source-control-support

and then this one, which explains very clearly what to do and not to do:

https://community.appeon.com/index.php/articles-blogs/tips-tricks-techniques-articles/17-powerbuilder/227-tips-on-using-git-with-powerbuilder

I've pasted the most important stuff of this previous link at the end of my comment. (sorry for all the bold, I'm only trying to point out what is important in what follows):

This second link explains how the pbl upload works and indeed ... there is no need to separate the pbls from the source codeThe advice I gave in previous answers is wrong, sorry for that, but that's how we work with other source control.

The trick is that when you first do an "add to source control" from the powerbuilder IDE, the pbls will be initially uploaded. After that initial upload, it should never upload the PBLs anymore when doing commit and push, only the exported *.sr? files will go to the server.

Do NOT do a "Clone", a new developer should "connect to the workspace" and that way he/she should get everything. "another user still needs to use PowerBuilder > Connect to Workspace to download and set up in his development environment. It doesn't work if you simply copy the entire workspace folder over to the other user's machine. "

A new developer who has connected for the first time, will get the 'old, initially uploaded' pbls, when the project was "added to source control" at the start. So the newly connected developer also has to do a REFRESH.

When you do a PUSH, the pbls don't go to the server (or at least they shouldn't ).

When you do a PULL, you should not get the pbls again, you should only get the exported files which then will be build into your local pbls.

The "Upload PBL, followed by a PUSH" option, should only be used if after creating a new pbl when after some time in the project, you have created or added a new pbl.

Is maybe one of your developers using this "Upload PBL" all the time?

You have probably read all of this before, but maybe you missed something since you said your English is not perfect.

Just my 2cts. on how I think it should work, if it doesn't then there's a bug. Good luck! Here's an excerpt of the second link I gave you:

---------------------------------------

After you have uploaded your workspace using PowerBuilder, another user still needs to use PowerBuilder > Connect to Workspace to download and set up in his development environment. It doesn't work if you simply copy the entire workspace folder over to the other user's machine. Nor will it work if you use a Git client to download the workspace. The PowerBuilder Git feature will only be activated for the other user after he uses Connect to Workspace to set up his workspace. 

Another thing is that as the associated data for the Git settings for a workspace is saved in the registry tied up to the workspace path, The PowerBuilder Git feature will be disabled if you move the workspace to another location.

#2 When to use the Refresh menu item

There are mainly two situations when you need to use the Refresh function. 

  • The first time you do the Connect to Workspace to set up your local workspace. 
  • After you directly modified the source code outside of the PowerBuilder IDE.

The reason behind this is that PowerBuilder IDE doesn't load the code directly from the source code files. It only displays the code saved in the PBLs. Ideally, PowerBuilder should be managing all the synchronization automatically. The reality is that PowerBuilder only pulls the source code in to PBLs when you do a Git Pull. On the other hand, it only exports an object to the source code folder when you save it in the IDE. Synchronization of anything changes happened in other manners have to be taken care of manually. 

So, as PBLs are only uploaded once during Add to Source Control. The later code changes are not reflected in the PBLs on the server. So the first time you download the code from the server, you need to do a manual Refresh.       

 

#3 When to use the Upload PBL menu item

Normally you don't need to use this feature. When you do the "Add to Source Control" and do the first Git Push for setting up the repository all the PBLs in your workspace will be uploaded to the server automatically. 

By default, PB will not commit or push the PBLs to the server thereafter; Only the *.sr object source files will be committed and uploaded in later operations. If there are any changes on the server in the *.sr files, they will be downloaded and imported to the PBLs when you do a Git Pull. So it kind like the PBLs are dynamically built when you do a Git Pull. But the dynamical building process requires the presence of an skeleton PBL, which is why the original PBLs were uploaded when you set up the repository. 

Now, there is one situation you do have to use Upload PBL. That is when you add a PBL to the workspace. This is so that your colleagues will be able to get the skeleton PBL when he pulls in your changes from the server. 

Note: Upload PBL doesn't literally upload the PBL. It only commit the PBL and you still need to do a Git Push to really upload it to the server. 

Comment
There are no comments made yet.
ATK Gimmy Susan Accepted Answer Pending Moderation
  1. Saturday, 9 November 2019 09:44 AM UTC
  2. PowerBuilder
  3. # 4
Good morning.
 
Thank you all for the interventions, but back to the bomb.
Mine is a problem that concerns a working method and not a backup method.
Here we have dozens of projects, dozens of technicians and many consultants.
CLONE operations are performed many times in a day.
I find it impossible to think that you should always do magic (copying the pbls from a high folder, hooking the project back to git, excluding pbdom objects because they do not work, etc.)
The method in the 'user guide' is different, it is very simple. Run a clone from the workplace that is in the remote repo.
THAT'S HOW IT HAS TO WORK. THIS IS HOW IT WORKS IN OTHER DEVELOPMENT ENVIRONMENTS.
I'm definitely going to be wrong, but Appeon/manual doesn't tell me what.
It can't be that, after so long since the release of GIT functionality, it's still not usable.
We're still debating how to make clones (it doesn't matter if it's a Powerbuilder issue or a manual problem).
Sure with a few tip and tricks you can do something, but we are far from a linear use.
 
I repeat: I hope I am wrong something.
 
I'm waiting for suggestions from all over the galaxy.
 
=)
Comment
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Saturday, 9 November 2019 08:36 AM UTC
  2. PowerBuilder
  3. # 5

Here's an example of what I needed to do, using "mingw64". 

git rm --cached -r fileOrDirName

On the image you can see it took me several efforts to get it right :)

Comment
There are no comments made yet.
David Peace (Powersoft) Accepted Answer Pending Moderation
  1. Friday, 8 November 2019 16:38 PM UTC
  2. PowerBuilder
  3. # 6

In all my experience I would say do not put your PBLs in source control. It just doesn't work!

Our developers workspaces & PBLs are copied to a network share when they log off. A new developer working on the project would copy the workspace & PBLs to their dev machine and then connect to source control. Do a get latest etc and you are away.

That's got to be the simplest and safest way for an source control system.

That's my 2p worth....

Comment
  1. Miguel Leeuwe
  2. Friday, 8 November 2019 16:42 PM UTC
Hi David,

Well that's kind of what I'm trying to say: Only use Git to backup the pbl's, don't hook it up with the pbl's involved in the development libraries.
  1. Helpful
  1. Miguel Leeuwe
  2. Friday, 8 November 2019 16:44 PM UTC
But of course, any other means of backup can be valid, like a network drive, google drive, one drive, usb stick, etc :)

Personally, I have a little box at home to which I backup everything I don't want to loose in case of an office fire / bombing. I use "SyncThing" for that, simple and solid.
  1. Helpful
There are no comments made yet.
ATK Gimmy Susan Accepted Answer Pending Moderation
  1. Friday, 8 November 2019 14:36 PM UTC
  2. PowerBuilder
  3. # 7
Thank you for your post Miguel.
 
I opened it up a lot. From here I realized that we're all getting by somehow.
But that's not good. This cannot be the solution. I can't believe Team Appeon thought we should do this.
 
There is no real protocol of conduct. A protocol that does not generate errors.
 
What you suggested is precisely what we were doing, but the PowerBuilder user manual says we do differently.
If I run a clone (as am by textbook) if there are no PBLs Powerbuilder generates erroe.
 
oh my gosh...
Comment
  1. ATK Gimmy Susan
  2. Friday, 8 November 2019 16:11 PM UTC
Dear Miguel.

i open a ticket.
  1. Helpful
  1. Miguel Leeuwe
  2. Friday, 8 November 2019 16:21 PM UTC
Well done, "fortuna bro".
  1. Helpful
  1. ATK Gimmy Susan
  2. Saturday, 9 November 2019 09:06 AM UTC
Hi Miguel.

This is the instruction by Appeon



https://docs.appeon.com/appeon_online_help/pb2017r3/pbug/ch03s03.html

( user manual )



In clone method you need to have pbl in remote repo.







  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Friday, 8 November 2019 11:55 AM UTC
  2. PowerBuilder
  3. # 8

If they pbl files were pushed by a user before the .gitignore file was set/uploaded, then you might have to do something like this from the commandline:

git rm --cached debug.log nbproject/

 

See:

https://stackoverflow.com/questions/11451535/gitignore-is-ignored-by-git

 

It happened to me with some files on GitLab and this solved the problem.

Comment
  1. ATK Gimmy Susan
  2. Friday, 8 November 2019 12:54 PM UTC
Thank you Miguel for the answer. I appreciated her.



I'm asking you one more thing, because my bad English is fighting with the GIT manual and I don't understand.



This command keeps the PBL libraries safe on the remote repo ?

I need it, otherwise when a new programmer makes a clone I have problems.



I'm disconsolate. Too many bug and configuration issues with GIT.



Thank you early for the answer.



Gimmy
  1. Helpful
  1. Miguel Leeuwe
  2. Friday, 8 November 2019 13:17 PM UTC
To be honest I'm not sure about that. I don't think so, but keep a copy somewhere just in case before you do anything.



As I already said, my opinion is that the PBL files should be somewhere on Git, but in a separate "start repository" folder from the source code. In that folder or for that folder the ".gitignore" file should NOT exclude the PBL's. For all of the other folders, the ones connected to the source, the PBL's should be excluded so that if for example you recompile a plb or optimize a pbl this does not go to Git.

A new developer should get his initial set of PBL's from the "start repository" folder. If in that folder you keep the subfolders with the pbls (and maybe images, ini , pbr files, etc.) in it's own subfolders. Something like this:



this folder's .gitignore should ONLY include PBL files or other stuff like images, pbr files, ini files

------------------------------------------------------------------------

\git\start-repo-pbls\app\app.pbl

\git\start-repo-pbls\services\services.pbl

\git\start-repo-pbls\pfemain\pfemain.pbl

\git\start-repo-pbls\etc\etc.pbl



this folder's .gitignore should ONLY include *.sr? files (*.srw, *.srd, *.sru, etc. ), or other stuff like images, pbr files, ini files

------------------------------------------------------------------------

\git\myapplication\app\app.sra

\git\myapplication\app\w_mdi.srw

\git\myapplication\app\d_datawindow.srd

\git\myapplication\services\nvo_service1.sru

\git\myapplication\services\nvo_service2.sru

\git\myapplication\pfemain\u_dw.srd

\git\myapplication\pfemain\n_ds.srd

\git\myapplication\pfemain\w_master.srw

\git\myapplication\etc\w_more_things.srw

\git\myapplication\etc\str_my_pass.srs



When a new developer starts,:

1) gets everything from \git\myapplication

2) gets everything from \git\start-repo-pbls

3) copies everything from his start-repo-pbls on top of his myapplicaton folder

4) does a get latest version



Carefull ! I'm not at all an expert on Git so I would suggest you try this method with a small test application first.



You can choose to inlcude images, pbr, ini etc. files in either the "myapplication" folder as part of source control in such a way that when a users changes (let's say an image) that one is automatically available to others. Or you can choose to not include them, and add them together with the copy of the pbls that you have in "start-repo-pbls".

Now and then you should upload a recent version to "start-repo-pbls" in a "manual" way.

It's the same proces I explained here in some answer before.

:)

Hope it works out.
  1. Helpful
  1. Miguel Leeuwe
  2. Friday, 8 November 2019 13:21 PM UTC
My answer should have been shorter:

First of all, upload all of your PBL's to a new separate folder that's not in the libary list of your applications.



Then do a test.

- Create a new repo without a .gitignore, upload / push everything to it.

- Then create a .gitignore which should not upload your pbl anymore.

- See if that's not working.

- Do the command line thing with "git rm --cached debug.log nbproject/"

- Check if your pbl is still on git in it's original state.

  1. Helpful
There are no comments made yet.
ATK Gimmy Susan Accepted Answer Pending Moderation
  1. Friday, 8 November 2019 10:30 AM UTC
  2. PowerBuilder
  3. # 9
Ty Tom for your answer.

But the problem persists after 2017R3 build 1880.

 
After 201R2 build 1880.
It seems to me that the problem is the merges.
When a merge occurs, the system also attaches PBLs that are downloaded and create conflict.
 
See 4 attach
 
I really urgently need to fix it
 
 
Attachments (4)
Comment
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Tuesday, 5 November 2019 10:51 AM UTC
  2. PowerBuilder
  3. # 10

As a tip:

What we do, with another source control, is to always have a separate folder as a backup for the pbls. That folder we DO include in source control, but not the pbl's that we work with which are in the library list.

Now and then we copy the work-pbls to that backup-folder and that backup-folder we then PUSH. (So they are not the pbls that you use in your library list).

This way, if you setup a new user, the user can download the pbl's from the backup folder, put them in whichever folder structure you need, and then connect to GIT to do a "refresh", "getlatest" or whatever is necessary with GIT to get started.

 In other words, not every change of an object causes the pbl to be updated with source control, only the backup version, maybe once a week or once a month.

If a newly connected user has fetched latest versions, he'd have to make sure he'd delete any objects in the pbl's marked with a +. Those will be reflecting objects that would have been removed in the time passed from the latest push of the backup folder.

HIH

Comment
There are no comments made yet.
ATK Gimmy Susan Accepted Answer Pending Moderation
  1. Tuesday, 5 November 2019 10:05 AM UTC
  2. PowerBuilder
  3. # 11
Thank you Tom for the answer.
 
[cit]
In other words, the Git/SVN integration is like an add-on to create a bridge to export source code from PBLs to commit to the repository and retrieve source code from the repository to import to PBLs. So in order for a user to be able to set everything up when they use the "Connect to Workspace" operation, the PBLs also need to be included in the repository.
[end of cit]
 
Assuming it's important to send PBLs, how can I avoid conflict with each pull?
 
An early thank you for the answer
 
Gimmy
Comment
  1. Tom Jiang @Appeon
  2. Wednesday, 6 November 2019 03:08 AM UTC
After the initial uploading of PBLs (when you add a workspace to the repository), PB is designed to NOT commit PBLs in all other operations (unless you explicitly do a Upload PBL or commit using a third party tool, which by default would also include changed PBLs). So if everyone understands and not commits PBLs, there shouldn't be any confilict on PBLs.

There was a bug where PB commits PBLs when a conflict happens with some objects, but it should have been fixed in the latest release. Please update to the latest version of 2017 R3 1880 or 2019 2082 if you are on an old version.
  1. Helpful
There are no comments made yet.
Tom Jiang @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 5 November 2019 09:38 AM UTC
  2. PowerBuilder
  3. # 12

The implementation of Git/SVN integration does not change the fundamental architecture of the PB IDE. In other words, it does not change the fact that source code is stored in PBLs and IDE still directly interacts with PBLs for saving the changes into objects and load source code when you open an object.

In other words, the Git/SVN integration is like an add-on to create a bridge to export source code from PBLs to commit to the repository and retrieve source code from the repository to import to PBLs. That is why it still relies on the PBLs to work. So in order for a user to be able to set everything up when they use the “Connect to Workspace” operation, the PBLs also need to be included in the repository.

However, if you really do not want PBLs to be included in the repository, you may try the following workaround:

  1. When you first do the “Add to Source Control”, uncheck all the PBLs so they will not be committed to the repository. Note: Do not uncheck PBD files, because if you do not commit them, they will always show up every time you make a commit later. As PBDs are normally not updated frequently, it should not be a big problem to include them.
  2. Push the repository to the server.
  3. Connect to the workspace from another user. Note: You will see an error similar to the following. Just ignore and cancel it for now.
  4. Copy all the PBLs from the original project on the first user’s machine and put them in the corresponding folder in the second user.
  5. Do a Refresh to make sure any new changes to the objects are imported (this is only necessary when you connect to a workspace for the first time)
  6. When you need to add a new PBL to the project, just share it with other developers so they can put it in their corresponding folder in their workspace.
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.