[Feature]: Support Perforce as a VCS

[aatwi]

Contact Details

aatwi@murex.com

Feature Request

Some teams use Perforce instead of Git as their official VCS.
We need to support using Perforce for them to be able to use TCR on their production code.

Feature Description

TCR can do all the VCS operations with Perforce instead of Git.

Alternatives

• Use a temporary Git folder
• Use Helix4Git
• Explore Git-p4

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Mikado

• Run TCR on a p4 depot
  • Have p4 environment ready on our machines
    • Setup a test p4 depot
      • Create a p4 test subfolder under "dev" root depot
      • Populate the p4 test subfolder with code examples on which we can run TCR
    • Setup p4 environment on our machines (✅ @aatwi ✅@mengdaming ✅@philou)
      • Install p4 (✅ @aatwi ✅@mengdaming ✅@philou)
      • Get p4 licenses (✅ @aatwi ✅@mengdaming ✅@philou)
      • Setup local p4 workspaces (✅ @aatwi ✅@mengdaming ✅@philou)
      • Sync p4 test depot to our machines (✅ @aatwi ✅@mengdaming ✅@philou)
  • Update TCR so that it can use p4 as a VCS
    • Be able to trigger p4 commands from TCR
    • Refactor the vcs package so that it provides a VCS implementation agnostic interface
      • Rename GitInterface to an implementation agnostic name (API for other packages)
      • Move git-specific implementation into vcs.git sub-package
        • Create a git subdir
        • Move git_impl and git_impl_test to git subdir
          • Move git_fake_test.go to git subdir
            • Make newGitImpl public
            • Make GitLog.add public
          • Make command.go functions public
        • Rename git_file_diff.go to git_diff.go
        • Rename git_log_item.go to vcs_log_item.go
    • Rename GitError to VCSError in status package
    • Replace "git" with "vcs" in all parts of the codebase that are not git-specific
    • Create p4 implementation
      • Create vcs.p4 sub-package
      • Add p4 implementation
        • Define p4 equivalent for the following git operations (defined in vcs.Interface)
          • GetRootDir() string
          • GetRemoteName() string
          • GetWorkingBranch() string
          • IsOnRootBranch() bool
          • Add(paths ...string) error
          • Commit(amend bool, messages ...string) error
          • Restore(dir string) error stubbed
          • Revert() error stubbed
          • Push() error
          • Pull() error
            • run p4 sync on Pull call
            • update p4 sync so that it syncs only the workdir contents (instead of p4 workspace root dir)
              • add a function to retrieve p4 clientName
              • add a function to convert TCR basedir to p4 path (using p4 clientName and rootDir)
          • Stash(message string) error stubbed
          • UnStash(keep bool) error stubbed
          • Diff() (diffs FileDiffs, err error)
          • Log(msgFilter func(msg string) bool) (logs GitLogItems, err error) stubbed
          • EnablePush(flag bool)
          • IsPushEnabled() bool
          • IsRemoteEnabled() bool
          • CheckRemoteAccess() bool
        • Create a test environment for p4-specific operations (shell command stub)
        • Add "-c clientName" option in all p4 command calls (using by default clientName from p4 info)
    • Have TCR know if it should use p4 on the provided work directory
      • Provide a configuration option to tell TCR which VCS to use
        • Use a default vcs (git seems the best candidate)
        • Have a command line flag to specify the vcs to use
        • Have a configuration setting allowing to specify the vcs to use
    • Make sure p4-specific tests can run within GitHub actions
      • Look for a GitHub action that installs at least p4 client command -> there is one, but requires to have a p4 server running somewhere -> discarded
      • See if there is a way to have a p4 workspace to that we can test against it (in-memory would be ideal) -> discarded
      • Chosen option is to stub out all p4 command calls when running in GitHub actions
    • Document how p4 VCS is used (README, etc.)
    • Update tcr check so that it's able to check either git or p4 environment (or both?) depending on workspace stubbed
    • Update tcr trace depending on which VCS is used to show only meaningful information
    • Customize menu shortcuts depending on the VCS being used
      • Remove "push" shortcut when running with p4 as Push does nothing when in p4
      • Remove "P -> Turn on/off VCS auto-push" shortcut when running with p4 as it's meaningless with p4
      • Replace "L -> Pull from remote" with "Y -> Sync"

Parking lot

• Move command.go to their own standalone package
• Add a tcr command line option to specify the p4 clientName
• See if there is an easy way for TCR to automatically detect the underlying VCS
  • see if we could use the command env P4CLIENT=xxx p4 status (rc = 0 when cwd is in xxx workspace, rc=1 otherwise)
• Move "polling-period" configuration value key from "git" to "vcs" #228
  • Update config/param_polling_period.go
  • Prepare a script to automatically update tcr/config.yml once tcr version introduces this change