I have trunk and a release branch. If I fixed a bug in release branch, I definitely should integrate the fix back to trunk. However, I didn't find a command dedicated to integrate such a single change list; did I miss something?
To integrate changelist 100, for example, you'd use:
p4 merge //releasebranch/...#=100 //trunk/...
p4 resolve
p4 submit
(If you have an older Perforce server you'll have to use 'integ' instead of 'merge'.)
Note that '#=100' means the same thing as '#100,100' in this context.
I have used this:
p4 integrate -c 625466 //SrcPath/...#622912,#622912 //DestPath/...
Where CL 622912 is the one we want to integrate, and CL 625466 is the new CL.
Related
I have a dev branch with many changes (files added, deleted...). The dev branch is very different from the main branch.
I want to make my dev branch be exactly the same as the main branch in current state (as if I just created it).
Integrate do not fully match the branches. added files in the dev branch are not being deleted.
What is the best way to do it?
Delete the dev branch and re-create it?
Thanks in advance
Delete the dev branch and re-create it?
If you do this you will probably regret it; Perforce will see that you deleted all those files and try its very best to preserve the apparent intent behind that delete by doing things like propagating the delete back to the mainline at the next opportunity.
The command you want is p4 copy:
p4 copy //depot/main/... //depot/dev/...
or
p4 copy -b dev-branch
(or whatever)
Unless you want the history to be exactly as if you'd just created it. Then:
p4 obliterate -y //depot/dev/...
p4 populate //depot/main/... //depot/dev/...
Is it possible to create branches in Perforce in a similar style to Git? I.e. without creating a new folder.
I would prefer for my client to manage the branches transparently whilst I work against a single copy of the directory tree on disk.
It seems awfully wasteful for the client to create an exact copy of the entire tree if you're only modifying say a couple of files. I much prefer Git's workflow in this regard.
If it's not possible using straight Perforce I'm happy to move to GitSwarm.
For info I'm running Perforce version 2015.1/1233444.
Possible yes, but with the centralized version of the system it involves a bit of 'magic'. Basically, the branch part doesn't need to involve the client at all anymore. Take a peek at p4 populate. That'll create another folder on the server, but won't do anything locally. Then you can edit your client workspace to map the branched files instead of the trunk files, and it'll just re-sync over top the files on your disk.
Now, having said that, if you wanted to take a look at our DVCS version of working, then you can just do "p4 switch -c " and it'll create a new branch locally, switch your workspace over to it (shelving any open current work in the process) and away you go.
My original answer was deleted because I thought a link was a better idea than repeating content. My mistake.
At any rate, I believe the DVCS features in Perforce Helix supply exactly the sort of thing you're after. In a blog I wrote in the subject (link here for reference) I explained how to create a new in-place branch with a single command:
p4 switch -c newBranchName
That will create a new branch with the name "newBranchName" and save any existing work in progress by default. To discover on which branch you're working you can use the switch command with the list argument as follows:
p4 switch -l
That would show you output like this, the asterisk showing that you're now working on the newBranchName branch.
newBranchName *
main
You can switch back and forth as you like, changing contexts as needed as often as you like. Your work in progress will continue to be saved on each branch in progress. When you're ready to merge your work back to main and push it back to the server, you can use the following sequence of commands:
p4 switch main
p4 merge --from newBranchName
p4 resolve –as
The first command switches back to the main branch, the second merges your work from the newly created branch into main, and the third resolves any potential conflicts automatically. If there are any conflicts that can't automatically be merged, then you can use the usual commands to walk through the resolution process.
Alternately, if you prefer to stick with Git, you can use that directly with our Helix Versioning Engine through our Git Fusion technology or use Git directly with our new GitSwarm technology. That is a pretty amazing option (in my opinion) as it makes it possible to mirror content automatically and bidirectionally between GitSwarm and the back end server. That way you get all the features of Git with GitSwarm (which itself is based on GitLab) and all the goodies from the rest of Helix.
Hope that helps!
If you use streams (Perforce's "managed" version of a branch, as opposed to doing completely ad hoc inter-file branching with arbitrary paths), it's pretty simple. As P4Gabe said, "switch -c" is a one-shot option on a local server.
On a shared server it's only a little more complicated because you have to do the "populate" explicitly (this is to keep naive users from accidentally branching lots of files lots of times on a shared server), but it's still only a few steps and it's something that you as an advanced user could script easily:
p4 stream -P (current stream) -t development (new stream name)
p4 populate -r -S (new stream name)
p4 switch (new stream name)
The equivalent is possible using ad hoc ("classic") branches as well if you have a good understanding of how client views work -- use populate to create the new branch, modify your client view to map the new branch into the namespace currently occupied by the old branch, and sync.
This blog post on what exactly "p4 switch" does might help if you're trying to engineer your own solution that's similar-to-but-not-quite the "switch" command: https://www.perforce.com/blog/150428/p4-switch-switching-it
I have the following situation of branches in a Perforce repository: There’s a mainline “trunk” and two release branches “1.0” and “1.1”. A branch “customer” with customer specific changes has been branched off the 1.0 branch. Now the customer wants to move to version 1.1. How can I merge the 1.1 branch into the customer branch? The customer specific changes should remain “on top” of 1.1.
Here’s a diagram for one affected file:
1.1 -(1)---(2)---(3)
/ \ \
/ \ \
trunk 100--(101)-(102)--103---104---105---106---107
\
\
1.0 ---1-----2--...
\
\
customer ---1-----2----*3*
The current version of the file I’m looking at is revision 3 on the customer branch.
If I choose to integrate branch “1.1” with target “customer” I would have expected that the common ancestor of both is found (revision 100 on mainline) and all revisions from there leading to the tip of the 1.1 branch are merged (the ones in parentheses).
Instead Perforce only offers to merge revisions 1 to 3 of the 1.1 branch, which fails because it misses the necessary changes that happened on mainline before.
How can I persuade Perforce to do this without having to look at each file manually and selecting the revisions to merge? Maybe the branching strategy is unsuitable? What else should I do?
When you try to integrate revision 3 from your 1.1 branch, Perforce will only tell you that it's integrating changes on that particular branch -- but revision 1 already contains trunk revisions 101 and 102. When merging, Perforce will identify trunk revision 100 as the common ancestor for conflict resolution.
It's been my experience that the integration you're trying to do should Just Work. Are you seeing changes missing in your integrated source (that can't be explained by improper conflict resolution), or are you just looking at the output of p4 interchanges?
I'd strongly suggest trying to merge the customer's changes into the trunk. It's going to continue to be a maintenance nightmare when a few months down the line the customer wants to upgrade to 2.0 + their custom changes.
If you don't want the customer changes reflected in your main project, take the time to restructure the code so that you can expose the customer's desired behavior with a build flag or build configuration file. Have both build configurations running in CI to ensure that future changes don't break the customer's build.
To make integrations easy, I would create a specific branches trunk_to_custer and 1.1_to_customer and then issue:
cd customer-workspace
p4 integ -b trunk_to_customer #change-number-at-which-1.1-was-branched
p4 resolve
perhaps an in-between submit here, and then
p4 integ -b 1.1_to_customer
p4 resolve
p4 submit
i'm preparing a seminary about p4 and i'm trying to find the best way to use the "Task per branch" methodology, now i'm using the following steps: (all by CLI)
Set my client to the root depot in order to create the new branches.
View:
//depot/... //myMachine/...
p4 -c myClient integ -v //depot/MAIN/... //depot/myBranchX/...
p4 -c myClient submit -d "Branching"
Change again my client aiming to the new branch.
View:
//depot/myBranchX/... //myMachine/...
p4 -c myClient sync
i'm wondering if there's a fastest/better way to do it. Specially working with huge repositories and branches.
Thanks!
M.
So... you want to create a branch for each task/bug and you want the newly created branch to mapped to client/workspace as if it was the trunk. And you want to be able to this via the command line or by running a scrip. Correct?
OK.
What is there a reason you want to adopt this workflow? Are you working on critical software, i.e., life/death scenario where every task is isolated and needs to be thoroughly vetted before integrating into the main line.
Unless you have a situation like above I would recommend against this workflow. Creating a branch for every task, especially in a large repository will eventually bring your Perforce server to a crawl. An similar situation was posted recently on the Perforce Blog as an Anti-Pattern (what not to do). Perforce Anti-Patterns Part 2: Overuse of branching.
Think about it.
If you still want to proceed, then you can achieve what you want by writing a shell script (DOS, Bash, Python**) that groups the above commands together taking a few arguments for the task/branch name etc. Comment if you need further help in doing this.
** preferred, then compile the script using py2exe as an executable for distribution.
I have a large source file in Perforce that has been split up into several smaller files in a branch. I want to create a branch view that can handle this, but perforce (2009.1) only sees the last of the multiple files. For example, I created:
p4 integrate //depot/original/huge_file.c //depot/new/huge_file.c
Later I split the huge file into smaller ones:
p4 integrate //depot/new/huge_file.c //depot/new/small_file_one.c
p4 integrate //depot/new/huge_file.c //depot/new/small_file_two.c
p4 integrate //depot/new/huge_file.c //depot/new/small_file_three.c
Then edit each of those (including //depot/new/huge_file.c) and submit.
Now I make changes to //depot/original/huge_file.c and I want to integrate those changes to //depot/new. If I do this manually, it works fine:
p4 integrate //depot/original/huge_file.c //depot/new/huge_file.c
p4 integrate //depot/original/huge_file.c //depot/new/small_file_one.c
p4 integrate //depot/original/huge_file.c //depot/new/small_file_two.c
p4 integrate //depot/original/huge_file.c //depot/new/small_file_three.c
But I don't want to do that every time I integrate -- this kind of thing belongs in a branch view.
Unfortunately if the branch view includes the same source file multiple times, the subsequent lines override the earlier ones. How can I create a branch view like this:
//depot/original/huge_file.c //depot/new/huge_file.c
//depot/original/huge_file.c //depot/new/small_file_one.c
//depot/original/huge_file.c //depot/new/small_file_two.c
//depot/original/huge_file.c //depot/new/small_file_three.c
When I integrate using this branch spec, I get only small_file_three.c integrated.
I was going to suggest that you use an overlay mapping (a means to force all the lines of the spec to be processed), but a quick perusal of the page put the kibosh on that:
Overlay mappings are only allowed on
client views and do not work with
branch views.
It looks like you'll have to script it. This page has some more info that might be of use to you (and emphasizes the fact that this can't be done, "Perforce does not support 1:many file mappings.").
Just as a matter of interest, but why?
Why not have huge_file.c not in Perforce, and then change your build system to assemble it out of the three smaller, source controlled, source files. Or even just #include them if you wanted real simplicity.
In other words, I'm wondering if your're trying to use the wrong tool for the task you want to do?