I'm wondering what actions results in the left part of the graph, i.e. the red dashed arrow? This was done by Unreal Engine's Perforce plugin, when I renamed this file and submitted this change. The action shows add if I highlight that revision, but according to legend, this is a merge w/ edit action, so it doesn't seem to match.
The right part is my test, using P4V's move/rename action, and the action shows move/rename, which matches the legend Add (branch w/ edit), so this one seems fine.
So, what exactly happened in the left part? Is it really a merge w/ edit? Is it a correct result if someone is doing rename? Is move/add the only correct result when doing rename?
Thanks.
It's a mind-twister but there isn't necessarily a mismatch.
First the actions: the first is an add because the new file is created in addition to the old one. In contrast, the second is a move/add because you're adding a file by moving it from the old location, hence the old one ceases to exist. Indeed, you start the whole exercise with one file, and end it with two (rather than with three, as you would if you performed two adds; or rather than with one, as you would if you perform two move/adds).
Now the arrows. You're right the naming seems completely out of touch with the naming of the actions. I have no idea why there's the inconsistency.
You're asking about the Merge w/ Edit specifically. Perforce has four similar but distinct actions that could have been used here: p4 integrate, p4 merge, p4 copy, and p4 populate. There are subtle differences that don't matter here. At any case, all these actions do "merge" the file so I think the naming is OK. Intuitively, I feel this could/should have been done by p4 copy (since the target didn't exist, so you didn't have to merge anything) but it's also perfectly possible that Unreal Engine decided to use p4 merge or p4 integrate anyway. That, I believe, explains why the arrow is a Merge. As for the w/ Edit, did you perhaps make a (textual) edit in the file while duplicating it?
Related
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.
We currently have a header file that sits in two different depots (identical copies), and whenever we update it, we have to manually make sure that the other copy is updated as well.
Is there a simple way to get perforce to enforce this? Or would I need to set up something with triggers? (I'm a bit worried about doing it 'properly' if so, don't have any experience with that).
I assume you'd need admin access to the perforce server to do this?
To do this with a trigger, you'd want to put a change-commit trigger on the file:
Triggers:
copy-always change-commit //depot/my/file.h "my-copy-script"
and then my-copy-script would run commands like:
p4 copy //depot/my/file.h //depot/my/other/file.h
p4 submit -d "copy my file to my other file"
But! Keeping two identical copies is an antipattern and you shouldn't do it. Keep one file and use client mappings, branch mappings, streams, or symlinks to make it look like it's in two places. The exact solution you use depends on why you think you need two copies of this file in the first place. :)
I'm having trouble performing a merge/integrate from branch1/sql/ to b2/sql
I performed a rename operation in p4v from _1.sql to _2.sql
Made a small change to _2 file
Submitted changes
Went to submitted changes, and tried to perform a merge/integrate on _2 to the other branch (b2/sql).
The problem is that p4v freezes at that point:
What am I doing wrong ?
BTW, I have the latest version: Version: Helix P4V/NTX64/2018.2/1666551
Based on the generated changelist description, P4V appears to be hopelessly confused and trying to integrate the file into itself rather than between the two different branches you specified.
Easiest fix is to run it from the command line:
p4 merge //depot/Engineering/INT-DEV/...#=CHANGE //depot/Engineering/projects/...
where CHANGE is the small change you're trying to merge (this is easier/safer than specifying the full file path, especially if you're dealing with a file that got renamed in one branch but not the other since it's otherwise easy to mess up entering one of the paths).
If the small change is the only change you've made since the last merge, you can just trust p4 to figure that out automatically and do this very simple command instead:
p4 merge //depot/Engineering/INT-DEV/... //depot/Engineering/projects/...
I have some files, like upgrade01.x and upgrade02.x, where the name defines some order. Due to external constraints, I must use this naming convention but I want so swap them, 01 become 02 and 02 become 01. I tried renaming update01.x to a temp name (without submitting it), then tried change update02.x to be update01.x but perforce doesn't let me do that.
I can submit the rename to something temporary, then rename one to the other, then the rename the temp, but is a monster pain. Also, the history looks really weird (but that might be unavoidable).
Is there a way to do this in one sane operation?
Doing the rename in two steps (rename both to intermediate names, then each back into the place of the other) might be the preferred option if you want the "identity" of each file to follow it to the new name (e.g. when you merge from other branches, you want merges to be remapped according to the new name rather than going to the old one).
If your priority is to have this happen in a single changelist, though, and you're not so concerned about whether the history preserves the notion of which file is which, I'd do it like this:
p4 copy upgrade01.x upgrade02.x
p4 copy upgrade02.x upgrade01.x
p4 submit
This will get you a nice neat little X in the revision graph (which I suspect is what you want), but not a true rename.
Merging to/from other branches will be a little tricky either way; if you go the true rename option, when you merge the rename to other branches you'll need to go change by change to repeat the process of renaming to something intermediate and then back (since the target branch will have the same constraint of not being able to rename onto something that is itself already open for rename). If you go the copy option, you'll need to manually specify which file to merge into which depending on what state each branch is in and whether there are outstanding changes requiring an actual merge.
Is there any easy way to exclude a specific changelist from p4 sync?
I want to sync up my code, but I don't want to fetch the changes from changelist #1337
Like: p4 sync //depot/source/... - //depot/source/...#1337?
The best way to accomplish this is just sync to head, and then use the 'Back out submitted changelist' function in P4V ('Submitted' pane, right-click the undesired changelist, select 'Back out submitted changelist').
This will create a new pending changelist in your workspace with the undesired changes removed.
It is possible by syncing to a range and using two commands to "skip" the changelist.
p4 sync //depot/source/... - //depot/source/...#0,#1337
p4 sync //depot/source/... - //depot/source/...#1337,#head
Note: you may have to specify the changelist on either side of the one you want to skip - not sure if the range is inclusive.
HTH,
Dennis
Ok this should work depending on what you want to do. Man I really miss git :(
If you simply want to sync and temporarily ignore a changelist you can do what the first reply said and back out the change list. Just remember to not check that change list in unless you want to wipe out the ignored changelist for the branch. However this approach will not work if you need to make changes to files that exist in the ignored changelist.
If you need to work with the same files from the ignored changelist you can do the following. One thing to note however, is that the ignored changelist will be pulled out of the remote branch until you are ok with them being in your code. (there is one other option but requires someone else to do something)
If you want to ignore a change list, and not get rid of it completely but simply be able to work on your code with it off to the side, the following will work.
Back out the changelist as previously stated.
Submit the backed out changelist to wipe out the changes in the remote branch. (don't worry)
Now do another back out but this time back out the chagelist created by the previous back out and shelve it. This back out of the back out will be a pending change list that is basically a copy of the one you wanted to ignore. Once its shelved you can go about your work, even in the same files. The down side is that now the ignored changelist only exist on your work space and its up to you to submit it or decide what to do with it at some point.
You can keep the ignored change list shelved until you know what you want to do with it. If, after you work on your code, you want to re integrate that chagelist and merge it with yours you can simply unshelf it and resolve conflicts.
So the (other option)
You could do the above with help from another dev with a perforce account (perhaps the one who's changelist you want to ignore) in this case you could have them back out the changelist and submit, then you could sync, then they could back out their back out. In this case the remote branch would not need to stay in weird state while you worked on your code. The big downside is, that you would have to do this every time you wanted to sync.
A better option would be branching before an issue like this arrises but that is not as easy or light weight in perforce as it is in git.
Hope one of these options help or spark a finale and perfect solution from some one else.