The workflow we are using is to not include the PBLs in the source control. WE use Orca for our build environment and after each build it generates PBLs from stretch using the source and then stores a copy of the fresh PBLs in a shard folder. I have a batch file that is included in the source control which will pull a copy of the latest PBLs from this shared folder. So when you are setting up a new dev environment you simply close the repo and then run the batch file to get the latest PBLs. I then go to the top of the workspace tree, right click and select refresh. This will look for any source changes and compile them into the PBLs. I didn't like putting the PBLs in source control because they tend to get large and slow down PULL/PUSHes.

Personally the PBL should go away. When saving an object it should still do the compile process so you aren't making changes with compile errors but the IDE should always treat the loose source files as the master. I use VSCode to do a lot of editing but I wrote a command line compiler that I can use from a VSCode build task so even if I edit code outside the PB IDE I can ensure that the code compiles before walking away.

Hi, I have the same question and I have tried a couple of ways to deal with it. My conclusion is that it is a bad idea to exclude the PBL's when using GIT since you want to have a complete and fully functional copy of your development folders on the remote GIT repository if you have to pull the project to a new computer or another folder. So you shouldn't put the *.pbl in the .gitignore file.

If you want to ignore files created when deploying an application, just put *.pbd, *.dll, *.exe and maybe som more filters in the .gitignore file. The .gitignore file must be in the root folder and in my case this is the same folder as my workspace file. 

For some reason the PBL's are marked as modified when doing anything with the objects inside a PBL. And I found out that it's better to leave them and not push them to the remote repository since you will get an error that the local PBL file can't be merged with the server version. Probably since the PBL is a binary file.

Yes, it's annoying and makes the list of changed files messy when using any external GIT client. It would be nice to be able to use filter in the list of changed files in the GIT client. Unfortunately this doesn't seem to be possible in GitKraken or Sourcetree. 

/Fredrik 

Hi Gimmy;

    Your SCM normally needs to just track the PB objects in your PBL's and not the PBL's themselves. The current Git/SCN SCN feature in PB 2017 R2 adds the PBL's into its repository by default and then basically ignores them. You can have the PBL's entirely ignored when you initially add your PB App to the SCM. So that would alleviate your PBL problem and also save lots of space in the SCM repository.

    I agree with Roland though that you should add the PBL's to any SCM. I have been doing this for decades - even with Roland's SCM (which is awesome BTW). The only time I do that though is when I am deploying any PB App into production. I take a complete snapshot of the entire App & ZIP it up. Then upload the ZIP file into the SCM. That way as Roland says, you easily restore the entire App from a given version. Not only is that handy for testing regression bugs, it makes adding a new PB developer to the App Team so much easier as you do not need to get into the nitty-gritty of using ORCA to get the new developer set-up.

   What I have learned over the 3+ decades of using PB and various SCM's is that SCC has taken on its own "art form". Even with various clients of mine using the same SCM software, each client seems to create their own ways of setting up and interacting with the SCM from their needs, standards and deemed use perspective. Its a very interesting area to deal with - no matter what IDE you use. Just my $0.02.

 HTH

Regards ... Chris

[cit.] page 75 of 'users_guide_for_pb_0.pdf'

After that, it will not
need to be uploaded or downloaded again whenever new or changed objects are uploaded
or downloaded. Instead, the PBL file on the local machine will be updated automatically
whenever objects are created or changed.
[end cit]

Then, why i have to trace *.pbl in GIT and not put them in '.ignore' ?

thy

GMY

This is a question that is good to ask for any source control system, not just GIT. Since the individual objects get exported and put into the source control repository, you don't need the PBL files in there. There are advantages to letting your source control have the PBL files. It makes it easier in the future if you wanted to get an old copy of the entire application. As long as it doesn't mark the PBL file read-only you should be ok.