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

Resolved Move from MSSCCI Git to PB 2019R3 Native Git

  1. Advice
0
Votes
Undo
  1. Tim Ford
    Tim Ford
  2. PowerBuilder
  3. Wednesday, 9 June 2021 16:15 PM UTC

Has anyone moved from Git using MSSCCI to native Git in PB 2019R3 and been able to maintain source control history? Given that native Git in PB (as of 2017R2) creates a sub-folder named "ws_objects" for the source controlled object files (*.sr?), is there anyway to migrate the source control history from the MSSCCI Git object files to the "ws_objects" sub-folder?

  1. Git
  2. PowerBuilder
  3. PowerBuilder (Appeon)
  4. Versioning
How to decide, whether email client is installed?
Application with Embedded database
Accepted Answer
Tim Ford
Tim Ford Accepted Answer Pending Moderation
  1. Monday, 14 June 2021 14:10 PM UTC
  2. PowerBuilder
  3. # Permalink

Thanks for all the replies. It looks like we're going to create a new repository using the PB 2019R3 IDE and archive the old repository with all the history.

Comment
There are no comments made yet.
Responses (5)
Tobias Roth
Tobias Roth Accepted Answer Pending Moderation
  1. Thursday, 10 June 2021 21:50 PM UTC
  2. PowerBuilder
  3. # 1

(Re-Post with correct account)

Hi Tim,

a few years ago we had the same problem.

We wanted to keep the source code history, but wanted also to switch from Team Foundation Server to git.

In the end we decided to transfer the source code history to a separate project within git without changing the folder system.

We have uploaded the current source code to another project with the Powerbuilder IDE.

As a result, we only have to work company-wide with one tool and the complete source code history was retained for analysis.

TFS to git: https://github.com/git-tfs/git-tfs 

Regards Tobi

Comment
There are no comments made yet.
Benjamin Gaesslein
Benjamin Gaesslein Accepted Answer Pending Moderation
  1. Thursday, 10 June 2021 07:21 AM UTC
  2. PowerBuilder
  3. # 2

Can MSSCCI be moved to git (regardless of Powerbuilder) with the history intact? If so, just move to git first and add all your PBLs and workspaces (from a currently working copy that was fully built without errors) to the repo. Then let PB do its thing by connecting to the git repo you just created using "Connect to workspace". PB will download the repo and move the source files to ws_objects. Manually delete all .sr* and .pbg files from folders *other* than ws_objects and commit and push your working copy to the git repo. Git will keep track of the changes, including changed paths. (git --follow)

 

Edit: wait, I misread the question, MSSCCI is already using git, innit? In this case there's less work, just migrate to native PB git, git --follow should just work.

Comment
There are no comments made yet.
René Ullrich
René Ullrich Accepted Answer Pending Moderation
  1. Thursday, 10 June 2021 07:07 AM UTC
  2. PowerBuilder
  3. # 3

Hi Tim,

To keep the history you have to move the objects to ws_objects directory structure youself. Use an external Git tool like TortoiseGit to move the objects. Also to do: delete PBG files, add PBL files

You will see the history also for the old (moved) objects if you use the Log of TortoiseGit and use the "Walk Behaviour" called "Follow renames".

HTH,

René

 

Comment
Benjamin Gaesslein
  1. Benjamin Gaesslein
  2. Thursday, 10 June 2021 07:43 AM UTC
In most cases there's actually no discernible difference between git mv /old/path/file /new/path/file and manually moving the file and then staging (git add /new/path/file) and commiting the change. Git does not actually track filenames internally.
  1. Helpful
There are no comments made yet.
Bruce Armstrong
Bruce Armstrong Accepted Answer Pending Moderation
  1. Wednesday, 9 June 2021 19:49 PM UTC
  2. PowerBuilder
  3. # 4

I didn't bother to try.  I just created a new repository for the native git approach.

Back in the day when we migrated from PVCS to SVN we went through a lot of effort to ensure that we carried all the source code change history across.  Looking back at that now I can't think of any time when that information was useful, and if I had needed it I could have looked it up in the old system (up to the point where we completely decommissioned it).  Given that the old repository will still be in Git for a while it doesn't face that issue.

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.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.