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
Related
We're working on an application that is being used by multiple customers, each having a different version of the app.
Our team is currently following the Git Flow branching strategy, but we've been hitting a wall on maintaining a single master branch.
For example:
Customer A has v1.1.2
Customer B has v1.1.4
We have fixed a vulnerability for Customer B in v1.1.4, and updated the version to v1.1.5 in the master branch.
Now Customer B has asked for the patch fix in their version, but does not wish to update to v1.1.4 as of yet.
This fix then gets versioned as v1.1.2.1 (still on its release branch).
We are currently maintaining multiple release branches and pulling in feature branches in as needed, but we feel this isn't scalable in the long-run.
Is there a recommended solution or branching strategy for this?
Maybe you should create release every x.x.x version also fix your bugs on x.x.x.x versions and your customers can use this versions.
So there can be many x.x.x version. You can think this x.x.x versions are kinda major.
Did you tried looking for oneflow approach where you create the new branch from previous release.
Try having a look in this https://www.endoflineblog.com/gitflow-considered-harmful
There are two main updates - new features and security updates. The new features can be maintained per customer as per the version numbers. However, the security updates can be given as a patch that is available from v1.x.x onwards. This would decouple the vulnerability fixes and the feature updates. You could put the patches in a specific branch and someone could merge their given branch with the latest on the security patches branch.
You could send an email everytime there are new security patches.
My suggestion is to move your Softwares components to multiple seperate repositories.
You can then include them as subrepositories in different states in the different branches/repositories (you would have tp create a branch or repo for each customer).
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/...
I am looking for best practices using branches in RCS.
I had read the man page for rcs and ci and also browsed at the following links:
http://www.gnu.org/software/rcs/manual/html_node/Concepts.html
http://www.gnu.org/software/rcs/manual/html_node/Quick-tour.html
Suppose i have revision 1.3 on tip of the trunk.
I now want to change file 1.2 (as 1.3 have several other changes I cannot yet use).
I understand I can create branch on revision 1.2 using ci -r1.2.1
My question are the follows:
1. Do I need to set a lock on the file? If so, on which revision?
2. If no lock set, I cannot use -u flag in order to keep the file in my local dir. In case I wish to do so, is it still possible without co the file again?
Side note: I feel RCS does not suit my company needs however migrating to another system is not my decision to make, so currently I need to keep working with it.
I'm looking for much the same thing, but seeing you've had no answers, I'll offer my current practice:
I use branches for development, not for keeping different variants going in parallel. The trunk is reserved for my best, presumably working, code on the and I try not to check in anything there that might break it. I branch the code when I want to start a line of development that will take some time, break it for a while, is an experiment I might have to be abandon, etc.
To start a new line of development I change the default branch to a new branch off the trunk rev that's to be the base of my code, and force a checkin onto that branch, with:
rcs -b1.2.1 foo.cpp
ci -f1.2.1 -l foo.cpp
Now I can dive in to developing the branch, and my next check-ins will go onto the new branch instead of onto the trunk. Whether you lock a revision or not is only relevant to whether you intend to modify the working file.
You're correct that you can't keep both revisions, trunk-tip and branch-tip in the same folder; they have the same file name. But you can check out one of them with a -p switch which forces the output to stdout (instead of to a local file) which you can then redirect into a sub-folder, or to a local file with a unique name.
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.
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.