• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • Tortoise SVN: Add To Source Control for Common PBLs...

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (3)

Resolved Tortoise SVN: Add To Source Control for Common PBLs...

  1. How-to
0
Votes
Undo
  1. Erick Bergsma
    Erick Bergsma
  2. PowerBuilder
  3. Wednesday, 12 December 2018 16:06 PM UTC

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?

Datawindow computed fields - performance issues.
Uploading Blob to MS SQL Server
Accepted Answer
David Peace (Powersoft)
David Peace (Powersoft) Accepted Answer Pending Moderation
  1. Wednesday, 12 December 2018 17:05 PM UTC
  2. PowerBuilder
  3. # Permalink

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
Erick Bergsma
  1. Erick Bergsma
  2. Wednesday, 12 December 2018 17:19 PM UTC
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. Helpful
David Peace (Powersoft)
  1. David Peace (Powersoft)
  2. Wednesday, 12 December 2018 17:31 PM UTC
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
  1. Helpful
Erick Bergsma
  1. Erick Bergsma
  2. Wednesday, 12 December 2018 18:05 PM UTC
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. Helpful
There are no comments made yet.
Responses (3)
Erick Bergsma
Erick Bergsma Accepted Answer Pending Moderation
  1. Tuesday, 18 December 2018 13:50 PM UTC
  2. PowerBuilder
  3. # 1

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.
Erick Bergsma
Erick Bergsma Accepted Answer Pending Moderation
  1. Monday, 17 December 2018 18:16 PM UTC
  2. PowerBuilder
  3. # 2

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
Load more comments
Erick Bergsma
  1. Erick Bergsma
  2. Tuesday, 18 December 2018 13:49 PM UTC
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. Helpful
Tom Jiang @Appeon
  1. Tom Jiang @Appeon
  2. Wednesday, 19 December 2018 01:39 AM UTC
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. Helpful
Erick Bergsma
  1. Erick Bergsma
  2. Wednesday, 19 December 2018 12:41 PM UTC
Thanks Tom. Appreciate the clarification.
  1. Helpful
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.