2

Familiar with git, first time using perforce.

I am working on my own feature which I would not like to push to mainline remote repository.

I need something like git remote branches where:

  1. I can commit my changes. Something like git commit

  2. I can push to remote private branch which does not merge. Something like git push remote my-branch

  3. Can merge changes from mainline into my branch. Somthing like git merge master.

I am trying to understand p4 branches, but the confused with the terminology a lot between p4 integrate and p4 branch. Moreover all the steps lead to p4 submit which submits to the mainline instead of my branch. Is there a way to submit to remote private branch?

I have tried the p4 branch steps here: https://www.perforce.com/perforce/doc.973/cmdguide/html/branchin.htm But it did not lead to submitting to private remote branch.

roadrev
  • 67
  • 5
  • Can you share the exact steps you tried, and why you think that it was causing you to submit to the mainline instead of your branch? Maybe you just overlooked something simple? Include as much detail as you can. Meanwhile, Sam's marvelous answer will probably give you most of the background you need. – Bryan Pendleton Oct 11 '19 at 01:10

1 Answers1

5

Perforce has a DVCS mode that's somewhat git-like, but unless there's a compelling reason not to (like limited connectivity or severe resource constraints on the server), the typical way of using Perforce is to do everything directly on the central server (the "remote repository"). p4 submit in the typical model is essentially git commit + git push, because your "commit" goes directly to the remote server.

So when you create a branch, you're doing that on the server as well. Branches in Perforce are simply folders that are copied from other folders (with lots of merge tracking semantics built on top of that simple copy operation), so to create your new feature branch from //depot/main you might run something like:

p4 integ //depot/main/... //depot/features/road-rev/...
p4 submit

This creates a new branch in the depot (as a folder called features/road-rev), and also syncs it to your workspace, so now all you need to do is:

cd features/road-rev
p4 add <new files>
p4 edit <existing files>
<etc>
p4 submit

Changes you make in the road-rev branch are completely separate from the main branch. To pull in newer changes from main you just repeat the same integ command you used to create it, but add a resolve to handle files that need merging:

p4 integ //depot/main/... //depot/features/road-rev/...
p4 resolve -as
p4 resolve
p4 submit

If you run the integrate command in the opposite direction (i.e. swap the order of the arguments), then changes get merged in the other direction. Once you grok the concept that you can use integrate to arbitrarily push changes from one set of files to another, branching is a very simple matter of defining different sets of files (usually as top-level folders) to represent different branched variants of code -- this is called "inter-file branching".

If your admin has configured your depot to use streams the workflow is a little bit different (streams are "managed branches" that are meant to feel a little bit more like the git branches you're used to -- you can only have one stream in your workspace at a time, and you use the switch command to switch between them, rather than defining a client view that maps arbitrary branches/files to arbitrary parts of your workspace). You still have the same underlying representation of different branched variants being different folders in the depot, but there's a whole bunch of syntactic sugar on top that sort of hides that representation. To create a feature branch from a stream you'd do:

p4 switch -c road-rev

which is similar to git checkout -b road-rev.

Samwise
  • 68,105
  • 3
  • 30
  • 44
  • This does solve my issue. None of the steps I found online explained in this manner and hence I never cd'ed into the branch directory. This answer should help people setup branches. The most different thing I found while using perforce is that not a lot of users create branches for themselves and hence not a lot of content about it online. – roadrev Oct 11 '19 at 17:52
  • Because Perforce's branching is so flexible, a lot of people have different preferred workflows, so people looking for "how do I make a branch" will end up sifting through a bunch of ways of doing it and come away with the impression that it's a lot more complicated than it needs to be. What I explained is the absolute simplest way of getting started; you might eventually find that you want to set up client specs per branch, create branch specs to manage your views, etc, but the fundamental concept of "a branch is a depot folder" will stay the same. :) – Samwise Oct 11 '19 at 18:40