1. Erick Bergsma
  2. PowerBuilder
  3. Wednesday, 12 December 2018

Our migration to PB 2017 is going nicely now, and the next step is to start using SVN for Source Control.

Our PB9 code was all in VSS, and we're going to start all new in SVN with PB 2017

Here is the issue...

All the PBL from the "main" application are going on well.

I have common PBLs as well.  Since several of our applications use the same common PBLs, they are in separate directory on our DEV machines, and the Build Machine, and we are expecting them to go in separate directory in the SVN Repository.  Using the "Add To Source Control" in PB 2017, the Common PBLs didn't get "versioned".

When PB built the list of objects to add to SVN, the common PBLs located outside of the "working directory" we not added.

How can I PB to create the ws-objects folder for these common PBLs?

Erick Bergsma Accepted Answer Pending Moderation
0
Votes
Undo

Is there anyone out there that is having success with the PBSCC Proxy and SVN?

is that a viable option?

Comment
There are no comments made yet.
  1. Tuesday, 18 December 2018
  2. PowerBuilder
  3. # 1
Erick Bergsma Accepted Answer Pending Moderation
0
Votes
Undo

Well...mixed bag of good and bad...

In the end , I created 1 WorkSpace for all applications that use the same common PBL.

That kind of forced me to put applications that are not really in the same group, into the same workspace...but we can deal with that.

Added that WorkSpace to SVN and then it's easy for other developers to "Connect To Workspace" and get all the objects.

However, in updating our documentation for Builds, I am failing to see how, in PowerBuilder 2017, to see what objects have been changed!  Using the SVN client that comes with PowerBuilder 2017, the familiar recycle icon is gone.  In fact, visually, in PB, I seem to have no way to know what objects in my Dev Space don't match objects in SVN.

Hoping that I messed up something in the configuration.

Anyone have similar issues...and solutions??

 

 

 

Comment
Thanks Tom.

From some testing I did, I can see that when I make a change to an object in my DEV workspace, it automatically marks the object with a Checkmark as opposed to the dot. Seems to indicate that my version of the object is different than the SVN version.

If I undo the change, then it reverts back to the dot...so, to me, it looks like I am connected to the server.

I do have TortoiseSVN installed...but the practice for years as a developer in the several clients I have worked at is that you can manage the CheckIn CheckOut all through PB, and not have to rely on an outside tool to verify that there are changes to pull in.



  1. Erick Bergsma
  2. Tuesday, 18 December 2018
Hi Erick,



SVN doesn't have the concept of checked out like VSS. The checkmark in this case is an indication that you have uncommitted changes. It doesn't mean the changes between your local object and the one on the server; it means the changes between your current object and the original state before you modified it locally. These states are all saved locally in your checkout folder (in the .svn hidden sub folder). Essentially you can shut down your connection to the server and still be able to make changes and revert the changes. Basically you only connect to the server when you need to do a commit or update.



Regards,



Tom Jiang
  1. Tom Jiang
  2. Wednesday, 19 December 2018
Thanks Tom. Appreciate the clarification.
  1. Erick Bergsma
  2. Wednesday, 19 December 2018
There are no comments made yet.
  1. Monday, 17 December 2018
  2. PowerBuilder
  3. # 2
0
Votes
Undo

The way we have resolved this is to have the folders under the normal workspace folders and then share them within the SSC. So if an object is changed in one application it is automatically changed in other with a get latest.

People might have different ideas.

Cheers

David

Comment
Thanks David...let me see if I got this right...



c:\AppDev\WS1\

- WS1/AppPBLs

- WS1/CommonPBLs



c:\AppDev\WS2

- WS2/AppPBLs

- WS1/CommonPBLs



Like that?
  1. Erick Bergsma
  2. Wednesday, 12 December 2018
Not quite, I think my explanation was not accurate....



What we have is shown below:



TopFolder - This is the root for the workspace in source control

TopFolder/Apps - This is the folder for the Application Specific Code

TopFolder/Shared - This is the folder with the shared code



Then within Apps

Apps/Application1

Apps/Application2



Then within Shared

Shared/Share1

Shared/Share2



Hope this helps.

David
Thanks David. Let me see how that pans out in a Sandbox.

We were planning to have each major application in a separate WorkSpace, like they are now in PB9.

With this model, sounds like one WorkSpace for everything that uses the same common PBLs.

Not sure if that's going to work well here...but I'll try.
  1. Erick Bergsma
  2. Wednesday, 12 December 2018
There are no comments made yet.
  1. Wednesday, 12 December 2018
  2. PowerBuilder
  3. # 3
  • Page :
  • 1


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