1. David Serrano
  2. PowerBuilder
  3. Friday, 9 July 2021 11:06 AM UTC

Hi!
I'm trying switch one of our projects from native Source Control to GIT. I'm using PB2019 R3 Build 2703 and SourceTree as an external Git client.

The thing is I'm having issues with the PBL files every time I try to merge branches, mostly when there's a conflict.

I read somewhere that I should add all PBLs to .gitignore, but GIT still detects that there's pending changes on the PBLs to be committed.

Currently, my .gitignore (located in the root folder of my PB project, next to the .pbw file) contains just this:

*.pbl
*.pbd
*.pbg
*.user.opt

I've tried using the "Stop tracking" option on SourceTree, to no avail. EDIT: When I stopped tracking the PBL, the whole PB Target could not be opened for some reason.

Any advice on how to solve this??

Thanks in advance.

Kevin Ridley Accepted Answer Pending Moderation
  1. Wednesday, 14 July 2021 12:25 PM UTC
  2. PowerBuilder
  3. # 1

Another option would be creating a new repository and basically starting from scratch, but keeping your old repository for object history.  Then you never add the PBLs in the new repository and you're all set.

Comment
  1. Kevin Ridley
  2. Wednesday, 14 July 2021 14:28 PM UTC
Orcascript is your friend for that.
  1. Helpful
  1. Benjamin Gaesslein
  2. Thursday, 15 July 2021 07:00 AM UTC
Yes, if you're willing to go slightly mad trying to make it work. :) And it's very slow, especially with large applications and complicated inheritance trees. In my case I need at least two passes in orcascript to get a working copy from just the source files. If you're working on a small app with just a couple of PBLs it's probably more feasible to do it this way.

The native GIT integration still isn't perfect but with some care (see my answer) having the PBLs in the repo is a definite plus.
  1. Helpful
  1. Kevin Ridley
  2. Thursday, 15 July 2021 13:21 PM UTC
Agreed it's not perfect. Another option is to keep the pbls on a network drive or even a separate GIT repo to get new users started.
  1. Helpful
There are no comments made yet.
Benjamin Gaesslein Accepted Answer Pending Moderation
  1. Monday, 12 July 2021 11:47 AM UTC
  2. PowerBuilder
  3. # 2

Hi David,

.gitignore entries will only cause git to ignore new files, not the ones already in the repo.

I would strongly advise against removing the PBLs from git, as this is bound to break PB integration. I don't think cloning a repo and opening it in PB will work if you do this. What I would do instead:

When pushing changes to the repo, only commit and push the source files without PBL changes. Unless you're introducing a new PBL, you don't have to push those at all. (I'd still recommend updating the PBLs in git from time to time, like once after a new release, to keep them from getting too outdated) Whenever you pull from git, use the "Refresh" option in PB to update the local PBLs from the source files.

If you're getting PBL merge conflicts, revert your local PBLs before doing the merge.

Comment
There are no comments made yet.
Tom Jiang @Appeon Accepted Answer Pending Moderation
  1. Monday, 12 July 2021 10:17 AM UTC
  2. PowerBuilder
  3. # 3

Hi David,

After you add the .gitignore file, you also need to remove the PBLs from the repository. In TortoiseGit you have the "Delete (keep local)" RMB to do this. And then commit the changes. 

Note that you need to do this for all the branches. There is a catch. After you remove PBLs from branch A, you will get conflict switch to branch B, because it will try to restore all PBLs to the status of branch B. So I just delete the PBLs before switching to branch B. 

Then I switch to branch B and use the "Delete (keep local)" and commit. After that, there should be no conflict on the PBLs switching between branch A and branch B. 

Then you shouldn't have any conflict merging code between branch A and branch B thereafter. 

Regards,

Tom Jiang

 

 

 

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.