I want to overwrite all files in branch B with another branch A. The use case is:
I branched B from A
Made some changes on B
Made other changes on A
I want B to be exactly the same as A, all changes on B are discarded
I want all files on B to be exactly the same as A, all additional changes on B are discarded (updated)
Is these a quick way to achieve this?
p4 branch would lead to a new branch C. And p4 integrate would keep the changes on B.
One possible way is, remove all files of B, and copy all files of A to B, and then run p4 reconcile on B. It's a little complicated. Anyone know a quick way? Thanks in advance.
'p4 copy' will copy files from one branch to another:
https://www.perforce.com/perforce/r16.1/manuals/cmdref/p4_copy.html
The previous history of branch B will still remain.
If you wish for it to look as if branch B was always an exact copy of branch A, then you may wish to obliterate it and re-create it.
Note that 'p4 obliterate' completely removes data from Perforce, so should be used with care and backups should be taken before running it.
More information about this command is here:
https://www.perforce.com/perforce/r16.1/manuals/cmdref/p4_obliterate.html
Hope this helps,
Jen.
Related
I am trying to merge a file.
I have the main branch and another branch B that was branched from main.
Both branches have changes. The main branch was merged to B at some point; but the merge on B was undid directly afterwards. After some more changes on both branches I'm trying to merge again but perforce selects the incorrect base file revision from the main branch.
I need to be able to select the common base file manually so that it will do the merge correctly. Unfortunately I was unable to find any way of doing this. If anyone knows how to resolve this, that would be much appreciated.
If the merge was undone via the p4 undo command, you should be able to redo it with a regular merge operation by setting the dm.integ.undo configurable:
(p4 help undoc)
dm.integ.undo 0 Enable re-integration of undone changes
With that configurable enabled, the "credit" granted by each integration is considered to be nullified by an "undo" operation, making each previously merged revision eligible for a merge as if it had never been merged previously. (The default behavior is for the undo to be considered the same as an edit, so that it's combined with unmerged changes, but previously merged changes aren't re-merged.)
If that's not an option, the best solution is to use the -f flag. Specify the exact range of changes you want to merge, along with the -f flag, and the revision immediately before that range will be used as the base. E.g.:
p4 integ -f main/...#100,400 B/...
will use main/...#99 as the base for the resolve(s).
So in perforce, we have p4 integrate p4 duplicate p4 copy and p4 branch what's the difference and when should I use which?
C:\Perforce\test>p4 help branch
branch -- Create, modify, or delete a branch view specification
...
You can use this command to (optionally) create a branch spec for later use with copy, integrate, merge, and/or populate. Note that all of those commands can also take an on-the-fly mapping in the form of two file paths, and if you're using streams you don't use branch specs because the mapping is generated automatically based on the parent and child stream.
C:\Perforce\test>p4 help copy
copy -- Copy one set of files to another
...
Opens the target files in such a way as to create new head revisions that are identical to those of the source files. (This may in some cases overwrite changes in the target -- if you're using streams, there are guards on copy to help prevent this, but otherwise you should always use integrate unless you're absolutely certain that you want to overwrite the target.)
C:\Perforce\test>p4 help integrate
integrate -- Integrate one set of files into another
...
Opens the target files (and schedules resolves) in such a way as to create new head revisions that combine all outstanding changes from the source with existing changes in the target. Actually performing the merges is done via the resolve command prior to submit.
C:\Perforce\test>p4 help duplicate
duplicate -- duplicate revisions with integration history (unsupported)
...
Like it says, unsupported. This has specific use cases that you will hopefully never need to discover.
Suppose we have a single text file in 2 branches:
//depot/work/branch1/file.txt
//depot/work/branch2/file.txt
We also have a central source file here that both branches depend on.
//depot/work/ImportantFile.txt
I make local edits to ImportantFile.txt and branch1/file.txt, but I also want to duplicate those edits to branch2/file.txt because ImportantFile.txt now expects all branches of file.txt to conform to a certain specification. As far as I know I have only 2 options, neither of which are ideal:
Manually make the same edits on both files and submit both changes in a single changelist. The problem with this, is that I would like P4 history to know that these files are still 100% integrated, but the history will show that they were edited independently.
Only make edits to branch1/file.txt, submit just this file as well as ImportantFile.txt in one changelist, then immediately integrate the change to branch2/file.txt in a 2nd changelist. Now the problem is that I've broken the build for a minute or two until branch2/file.txt gets the required changes.
How can I edit a file, and directly integrate those edits to another file before I submit those edits to the first file?
First off: you may already know this (and have had to make peace with it for reasons beyond your control) but:
ImportantFile.txt should not be outside of your branching structure. If your versioned files depend on it, it needs to be versioned itself, and that means it needs to exist independently in each branch, because branches are a part of your versioning scheme. Alternatively, maybe file.txt should not be branched, if it's required that it be identical in all branches at all times -- why branch something that's not allowed to diverge? But I suspect that just branching everything is the better solution.
Now for the workaround. (If you can't fix the root cause as described above, you've probably got a lot of this sort of thing in your future.)
p4 copy //depot/work/ImportantFile.txt //depot/work/NotABranch/ImportantFile.txt
p4 copy //depot/work/branch1/file.txt //depot/work/NotABranch/file.txt
p4 submit -d "Not a branch! (wink)"
Make your edits in //depot/work/NotABranch and submit them. Nothing is broken because, as stated, this is not a branch, and so it's exempt from whatever policy it is that forces all branches to move in lockstep. Now you can do:
p4 integ //depot/work/NotABranch/ImportantFile.txt //depot/work/ImportantFile.txt
p4 integ //depot/work/NotABranch/file.txt //depot/work/branch1/file.txt
p4 integ //depot/work/NotABranch/file.txt //depot/work/branch2/file.txt
p4 resolve
p4 submit
The merge history shows that both branches of file.txt were pure merges from a single common source, and so future integrations between the two should recognize that they don't need to be re-merged.
Here's our situation:
We copied the contents of stream A, which was change to our security infrastructure up into main.
Then we merged the contents down into stream B.
Then we made some other non-related changes in stream B.
Then we realized the changes from stream A weren't working as well as we thought and we decided to back it out to be safe.
We backed out the revision that included the updates from stream A.
This had the effect of deleting some of the files and changing others.
We tested without the stream A changes, and everything worked.
Meanwhile, the developers made a couple of small changes in stream A and we are ready to merge stream A back into stream B.
The problem is, we can copy up to main, but we can't get those changes back down into stream B, as the "remove stream A" changes are newer. We want all the changes we previously backed out back in, as well as the new changes.
Is there any way to do this without resorting to a tremendous manual effort to either manually copy or manually merge everything?
Thanks.
Start by running p4 changes -i #n,n where n is the changelist number of the merge from main to B that contained the A changes you backed out. That gives you a list of changes, the first of which is n itself, and the rest are the changes in main that you will need to re-merge to B. However, you can't use 'p4 merge' to re-merge, but instead will have to use 'p4 integ -f'.
For example, say n is 1000:
p4 changes -i #1000,1000
Change 1000 ...
Change 994 ...
Change 991 ...
Change 866 ...
This tells you that you have to re-merge 866, 991, and 994 from main to B. If you weren't cherrypicking, you can assume that these are contiguous changes in main and that you can use 866 thru 994 as a revision range:
p4 integ -f -r -S //stream/B #866,994
p4 resolve
p4 submit
(This integ command example assumes that //stream/main is the parent of //stream/B. And you have to be in a //stream/B workspace to do this, of course. And for best results, you probably want to make sure your workspace is completely synced and that you have no open files before running the integ.)
I'm not familiar with Perforce streams, but traditionally Perforce does not have any special notion of backouts. Backing out a change simply creates an inverse changeset.
Therefore, to reapply a backed-out change, you should be able to just back out the backout.
You can always backout your backed out changelist. This way you'll get to the point where the first changes were made.
Bear in mind that all files history is saved so all changes are supposed to be easily recovered in situations like yours.
Your most recent change is the delete, so it wouldn't re-add the file as its already opened for delete. Run a p4 revert on that file, and then do a p4 add, it worked for me.
Let's say I'm at state A in my document. I then make changes B, C, and D (in order).
Is there a way I can keep changes B and D, but skip C?
Or, let's say I'm at state A in my document. I make change B, undo it, and then make changes C and D (so Vim has an undo tree with two branches). I then change my mind and decide I want to use B and D but not C.
How can I do this in Vim? I have the gundo.vim plugin installed, but I haven't used it that much.
Well, I'll take a stab at this and say: No, I don't think there's a way to do exactly what you want with vim.
gundo.vim adds a nice interface to vim's undo, but doesn't change its core capabilities. So I took a look at the official vim docs to see if there's any hints to whether it is capable of this:
vim docs: undo
User manual page about undo
Nothing about merging two branches together. I think ewh and ZyX are right: to get a general solution for merging B with D, vim would need either for
Bram to add it as a separate feature in a future version
someone to implement it in a plugin by integrating with something that can already do merges (like git/hg)
You can of course try to do it manually by having files with versions B, C and D as well as a few diffs open.
Note: If I misunderstood and you weren't wondering about a general solution and are looking for help with a specific instance of this, let me know and I'll see what I can do :)
Is there a way I can keep changes B and D, but skip C?
You're at state D. :w file.ext_D
Backtrack to state C. :w file_ext_C
Backtrack to state B. :w file.ext_B
:!kdiff3 file.ext_B file.ext_C file.ext_D
This gives a 3 way merge of the differences, but still you'd have to manually go in and choose every red line in D for each merge conflict. Not exactly an easy solution.
If instead you do
:!kdiff3 file.ext_C file.ext_B file.ext_D
Then the merge happens automatically (except for individual lines with multiple changes)
For more complicated scenarios it gets tougher.
Note: I'm not sure how a revision control tool is much help. You're basically doing something like creating a patch between B and D, and then subtracting the patch from C to D from it. It seems to me that revision control systems are usually designed to manage merges between different sources of changes, not changes along a single branch.
kdiff3 is available at: http://kdiff3.sourceforge.net/