2

My company has deployed a 2014.X version of Perforce (server & client). We have an existing Peforce stream depot.

They are investigating an upgrade to 2015.X, also known as Helix. One of the feature is a better integration with Git, called "GitSwarm", that is using a GitLab frontend integrated with Perforce.

I have looked into the documentation online but I have not found the answers to these questions :

I have a few questions :

  1. Can my existing stream depot, with its full history, be accessed via GitSwarm, once the update is done, or will we need somehow to create or migrate to a new depot ?

  2. If the former is possible, I assume from Git Fusion/Connector documentation, that we will only be able create Git repo based on a single stream ? So only a single stream at once will be available from GitSwarm ?

  3. Lastly, if I create a feature branch on GitSwarm side, and push it to the Perforce stream depot to merge, how will the git branch appear in Perforce ? As a new stream ? Or only has a branch ? Basically, do we have to merged back git branch on the main mapped stream on git side ? or are we free to merge back either on Perforce or Git ?

Sorry for the long post, but as GitSwarm is going to be deployed I guess many teams will face the same questions.

Xavier T.
  • 40,509
  • 10
  • 68
  • 97

1 Answers1

3

1) Yes, the stream's full history can be accessed from the Git side. One challenge with using GitSwarm with streams is that the stream view cannot be changed after the git repo is cloned. There's no way for Git to understand the underlying stream semantics or to follow moved content.

Exclude lines in the stream view do not play well with Git; it is possible to add files in Git that can then not be pushed into GitSwarm because they are explicitly blocked.

Import lines from the stream will be converted into submodules in Git.

2) Correct; each repo points at one stream depot. You can create multiple repos that each point at different streams depots. Individual streams in each stream depot can then be mapped to branches in Git if you desire. In general, your mainline stream should map to master in your Git repo.

3) Git branches are stored in a lightweight format, so while those changes go into the Helix server, they won't be visible as separate streams. You can explicitly map longterm branches in Git to streams in Helix using the repository configuration files. If you map streams to your long lived branches in Git you can merge either in Git or Helix.

Matt
  • 4,860
  • 1
  • 17
  • 15
  • Thanks for the answer. Regarding 3), basically the correct workflow would be to merge back in git on the branch mapped to the stream, and then git merge commit will appear as changelists on perforce side ? This seems to be the cleaner solution. – Xavier T. Nov 25 '15 at 17:41
  • Yeah, that's how we tend to work. It lets Git be good at what Git is good at, and Helix be good at what it is good at. – Matt Nov 25 '15 at 18:40