1. Floyd Edwards
  2. PowerBuilder
  3. Tuesday, 19 March 2019 16:03 PM UTC

Need some ideas from the group:

At my work, we are having a discussion about whether to put the pibbles in source control.

They main concern is keeping the pbl's in sync with changes made and pushed up to source control.

My theory is that if we exclude the pbl's, then do the following in order:

1. Merge the changes into the Master (Production branch).

2. Once merged, do a pull request from the master branch to update my local master repository.

3. Go into PB and do the "Refresh" option to update what PB sees.

4. Then do a "Full Rebuild" to get the local pbl's to be in sync.

My question is: would this way work to keep local pibbles in sync?

Olan Knight Accepted Answer Pending Moderation
  1. Tuesday, 19 March 2019 20:44 PM UTC
  2. PowerBuilder
  3. # 1

After the failure or previous source control tools at specific junctions in the life cycle of our main product, we finally just gave up.

At this time we have a separate folder for each release of the code. That folder contains ALL of the source code, the exes, the installer file, the installer EXE, the PFCs, the DLLs, the images....it contains absolutely everything related that release.

It's simple, and it works very, very well.

For daily development, the users manually back uip their code nightly.
Personally, I also back up my code weekly because paranoia is healthy.

YMMV.

 

Olan

Comment
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Tuesday, 19 March 2019 16:40 PM UTC
  2. PowerBuilder
  3. # 2

Yes, that should do it.

The only reason to keep the PBL files themselves in source control is like Chris says, to keep a record of the source code as of a production release. It makes it easier if you need to go back and fix a bug in an earlier release. If you are working on internal applications that wouldn't be useful but it might if the application is in use by external customers that aren't always on the latest version.

Comment
  1. Roland Smith
  2. Tuesday, 19 March 2019 18:46 PM UTC
I've only used GIT a small amount to test my PBSearch tool.

From what I've gathered from other posts, it can only connect to the main branch. If that is true, they need to change it.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Tuesday, 19 March 2019 19:17 PM UTC
Hi Roland;

Correct ... that is the current limitation within the PB IDE.

Regards ... Chris
  1. Helpful
  1. Noel Hibbard
  2. Monday, 15 July 2019 14:31 PM UTC
Floyd, you are exactly right. If you need to go back in time you can roll back to a specific commit, do a refresh to pull the source back into the PBLs and then do a new build.



The PB IDE doesn't allow you to change banchs but that doesn't mean you can switch branches from the command line ot something like TortiousGit. Just be sure to do a refresh in the IDE after changing branches or else the PBLs will not be in sync.



This constant need to do refreshes is a pain. The bare minimum for Git is implemented in the IDE so you are forced to do a lot of stuff outside the IDE which then requires you to remember to do a refresh. There really needs to be a way to programatically trigger a refresh. Like maybe a windows message or something like that which would trigger a refresh at the root level of your workspace.



Here is what we have proposed for a build environment. We will have one machine that is dedicated to producing builds. When we need to do a build this machine will perform these steps:



First I will fetch the latest source and force it to overwrite any changes that are on the build server:

git fetch --all

git reset --hard origin/master



I will then grab the commit hash with this command (When I am done building I will move the EXE and PBDs into a subfolder named with this hash):

git rev-parse HEAD



I delete any left over PBLs and PBDs left from the last build:

del *.pbl

del *.pbd



To generate new PBLs using the latest source code I use an Orca script named build.orc that looks similar to this:

----------

start session

set debug true

scc set connect property localprojpath ".\"

scc set connect property logfile "..\build.log"

scc set connect property logappend false

scc set connect property deletetempfiles "true"

scc connect offline

scc set target ".\target.pbt" "refresh_all importonly"

scc refresh target 3pass

build library ".\library.pbl" "" pbd

build executable ".\application.exe" ".\resources\application.ico" "" "y" newvstylecontrols

scc close

end session

---------



I then call the script like this:

orcascr190.exe build.orc



When the build is done I do:

copy *.pbd

copy *.exe
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 19 March 2019 16:23 PM UTC
  2. PowerBuilder
  3. # 3

Hi Floyd;

  FWIW: This is what I have done over decades of PB work and a plethora of SCM software ...

1)  Let the SCM only handle PB objects from the IDE in day-to-day work.

2)  When you release a production version of any App ... then create a new project related to the App's production release and only upload the related PBL's.

3) When a new PB developer comes "on board" - restore the PBLS from that last SCM upload (See #2)

4) Apply the "delta" to the restored PBL's from #1 by doing a GetLatest.

  The above approach allows both to exist in the SCM without the daily over-head of PBL change upload/downloads for the entire project team. Just my $0.02.

HTH

Regards ... Chris

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.